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ABSTRACT 


Autonomous Underwater Vehicles (AUVs) are now being introduced into the 
fleet to improve Mine Warfare capabihties. Several AUVs are under government- 
contracted development. Mission planning and data reporting vary between vehicles and 
systems. This variation does not pose an immediate problem, as only one AUV is 
typically in operation at any given time. However, as more AUVs are put into production, 
cooperative operations wiU become possible and consistent mission commands wiU be 
necessary for multiple AUVs. Without a single mission command language, multiple 
systems will require familiarity with multiple languages. 

Extensible Markup Language (XML) and related technologies may be used to 
facilitate interoperabihty between dissimilar AUVs and extract and integrate mission data 
into Navy C4I systems. XML makes archive maintenance easier, XML documents can be 
accessed via an http server, and, in root form, XML is transferable on the fly by 
stylesheet. 

This thesis presents an XML-based mission command for the command and 
control of AUVs. In addition, this thesis discusses XML technology and how XML is a 
viable means of achieving interoperabihty. Lurthermore, this thesis provides an example 
mission file using existing software, and demonstrates the future of XML in AUV 
technology. LinaUy, this work provides demonstration scripts and compehing arguments 
for the use of an XML-based mission command language to command ah AUVs. 
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EXECUTIVE SUMMARY 


The U.S. Navy has been participating in Mine Warfare since the eighteenth 
century. While advancements have been made in mining, advancements in mine 
countermeasures had come to a stand still until the past several decades. While some 
improvement has been made, any classification and neutra liz ation stiU usually involves 
the risk of an expensive piece of equipment, at best, or a human fife, at worst. 

Autonomous Underwater Vehicles (AUVs) are an increasingly popular solution to 
the problem of human involvement in mine hunting and countermeasures. Today, AUV 
technology is at a point that an individual AUV can be tasked to search for mines or 
collect bathymetry and environmental data. However, contracts for several different 
vehicles have been given to several different commercial companies. While each vehicle 
is intended for a separate area of operation, the probabihty that one command will one- 
day use several vehicles is strong. This is a problem because AUVs currently have no 
standardized mission planning language. As a result, multiple vehicles will require 
familiarity with multiple command languages and vehicles. 

Most AUVs are commercially developed, and thus contain proprietary 
information. One of the biggest challenges facing the Navy’s use of AUVs is the abihty 
of the vehicle to communicate with others and to interface with Joint Command & 

Control, Communications, Computers and Intelhgence (C"^I) systems. The lack of a 
common language creates a barrier between vehicles, and makes command and control of 
the AUVs more difficult 

A solution to this interoperabihty problem is the use of the Extensible Markup 
Language (XML) and related technologies to create a mission command language. XML 
can be used to write logically, consistent and complete tasking orders. In addition, related 
technologies, such as Extensible Stylesheet Language for Transformations (XSLT) can 
be used to transform the XML-based tasking order into a text-based command file to task 
the AUV, or can be used to transform text-based outputs into a desired format for 
uploading into Joint C"^I Systems. 
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A preliminary set of XML elements and attributes describing a mission was 
developed based on the command language for the Naval Postgraduate School’s (NPS) 
AUV. Some tags were chosen based on already existing tags in the DoD XML Registry. 
However, many of the necessary tags had not already been defined in other Namespaces. 
As a result, a proposed namespace specifically for AUVs was developed. 

In addition to the tagset, a XML Schema Document was developed to vahdate 
mission-tasking orders. Finally, as an experimental test, an XSLT template was 
developed to transform an XML document into a text file to be inputted into the NPS 
AUV Workbench, a virtual simulation of AUV missions. Using XML and related 
technologies, generating virtually any type of data file is possible. FoUow on work in this 
area includes the refinement of this language to be able to command all types of AUVs. 

Another area of future work is to transform the collected data from any AUV 
mission into a form that is both validatable and machine readable, again using XML. This 
data can be incorporated into existing systems such as the Global Command and Control 
System, and such future concepts as the Semantic Web. 

Finally, due to a hostile environment, underwater acoustic communications are 
fundamentally slow, insecure, and low-bandwidth. Other future work includes the 
development of binary compression, forward error correction, and XML digital 
signatures to work with AUV. Many of these issues have been addressed in other areas, 
and can be applied to underwater communications relatively easily. 
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1. INTRODUCTION 


A. THESIS STATEMENT 

Autonomous Underwater Vehicles (AUVs) currently have no standardized mission 
planning language and no uniform form for data output. The Extensible Markup Language 
(XML) and related technologies can be used to write logically, consistent and complete tasking 
orders. Data collection and metadata annotation can also be regulated. This approach wiU 
facihtate interoperabihty between dissimilar AUVs and extract and integrate mission data into 
Navy Command & Control, Communications, Computers and InteUigence (C"^I) systems. 

B. OVERVIEW 

AUVs are now being developed and introduced into the fleet to improve Mine Warfare 
capabihties. A family of diverse AUVs is being developed to accomphsh this broad task. Lor 
these AUVs to be operationally effective, mission planning and data aggregation needs to be 
simple and transparent to the user. With such messaging support, one person can task and collect 
data from multiple vehicles without having to learn several different systems. 

Several AUVs are under government-contracted development. Mission planning and data 
reporting vary between each vehicle and system. This does not pose an immediate problem for 
each AUV team, as only one AUV is in production, and only one subject matter expert (SME) is 
needed to mn tasks on an AUV for a mission. However, as more AUVs are put into production, 
commands wiU begin to get more than one AUV. Until a means to control aU of the AUVs with 
one language is developed, an SME wiU be needed for each type of AUV, leading to multiple 
SMEs within a command. 

XML and Extensible Stylesheet Language for Transformation (XSLT) can be used to 
create a common mission planning and data formatting language for AUVs is a cost-effective 
means of achieving interoperabihty. 

XML is a markup language and a World Wide Web (WWW) standard defined by the 

World Wide Web Consortium (W3C). XML is a markup language that provides stmctural 

information for documents. This stmcture defines the precise roles and relahonships in which the 

information must foUow within the document A markup language defines the stmcture of a 

particular document. The XML specification defines a standard way to add markup to documents 
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(Walsh, 1998). XML differs from other markup languages because it does not directly specify 
how information is to be presented, but rather defines the sfructure (and thus semantics) of the 
information. 

XSLT is a component of XSL (Extensible Stylesheet Language). XSL is a language for 
expressing style sheets. It consists of three parts: XSLT (a language for transforming XML 
documents), XPath (a language for defining parts of an XML document), and XSL Lormatting 
Objects (a vocabulary for formatting XML documents). 

Think of XSL as a language that can filter and sort XML data, a language that can define 
parts of an XML document, a language that can format XML data based on the data value, lik e 
displaying negative numbers in red, and a language that can output XML data to different 
devices, like screen, paper or voice, (www.w3schools.com/xsl/xsl intro.asp accessed May 2003) 

By using XML and XSLT, interested and even competing entities will be able to 
maintain their existing formats without adhering to an agreed upon standard. In addition to 
avoiding problems of adhering to a standard, the use of XML and XSLT can avoid 
disagreements in creating a standard. 

C. OBJECTIVES 

The objective of this thesis is to address the command and control (C ) aspects of using 
XML to increase the utihty of AUVs. XML programming will be addressed. Current mine 
warfare doctrine will be discussed only to introduce the topic and the need for this study. AUVs 
will also be introduced to clarify the need for a master control document. The operational 
limitations of existing AUVs will be discussed with regard to how these lim itations affect C2, 
and also the future roles of AUVs and how a common vernacular could be helpful. 

D. THESIS ORGANIZATION 

Chapter II discusses the Navy’s mine warfare doctrine, the current practices and the 
future of mine warfare. This chapter also examines the use of AUVs in mine warfare. Chapter III 
examines various AUVs, their uses, and their operational limitations. This chapter also examines 
the C2 aspects of these limitations. Chapter IV provides a brief history of XML, XSL and XSD, 
providing a detailed description of the W3C recommendations and what they are used for. 
Chapter V demonstrates a candidate vocabulary using XML to write a master mission-tasking 
document. XSL is then used to write style sheets that exchange data. This chapter will also 
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address the XML tagset necessary to write these documents. Chapter VI includes test runs of the 
process of going from XML Mission document thm the XSLT to outputs to the AUV. Chapter 
Vn discusses the use of XML and XSL to exchange information between the GCCS MEDAL 
system and the AUV XML mission-tasking document. Chapter VIH addresses the impact of the 
Semantic Web on AUVs, and potential XML seria liz ation for underwater communications. Data 
compression and security aspects of XML and related technologies are briefly addressed. 
Chapter IX discusses other work that needs to be done for unmanned undersea vehicle (UUV) 
common control station similar to unmanned aerial vehicle (UAV) station, UAVs, Divers, 

Marine mammals. Submarines, Explosive Ordnance Disposal (EOD) teams, and Mine Warfare 
Underwater Control Station. 
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11. MINE WARFARE DOCTRINE 


A. INTRODUCTION 


The Navy and Marine Corps ‘Forward.. .From the Sea’ strategic concept has expanded 
naval operations into the littorals, an area where mines can be both a severe threat to the U.S. 
forces and a force multipher against other forces. An effective Mine Warfare (MIW) force is 
necessary to ensure the Fleet’s abihty to carry out operations both in the open ocean and in the 
httorals. (After CSS Webpage, 2003) 

B. MINE HISTORY 


Early mines, developed by naval inventors such as David Bushnell and Robert Fulton, 
centered on the idea of striking ship’s hulls with as explosive device. However, these keg mines 
were usually not in a stationary field, but were instead propelled by currents, harpoons, or 
underwater craft. These early mines were primitive, but inventors solved such problems as 
maintaining waterproof chambers for explosives and devising a trigger device. Until the second 
half of the nineteenth century, most major navies were not interested in mines, and saw them as 
weapons of states with weak navies. (After Mine Warfare History, 2003) 



Figure 1. Bushnell Keg Mine (From The Bushnell Keg Mine, 2003) 

During the second half of the nineteenth century, Russians in the Crimean War and the 
Confederacy used mines effectively during the Civil War. Mines became a common coastal 
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defense by the weaker naval powers forcing the U.S. Navy to investigate a variety of mine 
countermeasures. However, most mine countermeasures, while technically effective, were 
cumbersome, and no dramatic improvements from the previous fifty years occurred. (After Mine 
Warfare History, 2003) 

By World War I, mines began to play a significant role in naval operations, and out of 
necessity, mine countermeasures became critical, especially to the A lli es. Many advances in 
mine warfare occurred during WWI, and the United States acquired new ski ll s and equipment 
needed to sweep some types of modem mines more effectively. However, in the years following 
WWI, the U.S. Navy made httle progress in mine warfare, and in some areas, actually regressed, 
due to budget constraints, loss of experienced personnel, and lack of bureaucratic clout. (After 
Mine Warfare History (Web)) 



Figure 2. MK56 ASW mine, the oldest stiU in use (From Navy Fact File: Naval Mines, 2003) 


As in WWI, mine warfare played a key role in World War n. By the end of the war, the 
United States had the world’s largest minesweeping fleet, and had built up its own experience 
levels. WWn featured significant improvements in countermeasures, but the Alli es were never 
completely successful in neutrahzing the threat of mines. Throughout the Korean War, mines 
were easily one of the most dangerous weapons that the U.S. Navy faced. This threat caused 
renewed interest in mine countermeasures, which continued into the 1960s. However, in the 
early years of the Vietnam conflict, mines were not used in the same open ocean setting as 
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before. Mine countermeasures ships were required to operate in coastal areas, as part of a 
combined arms force. As a result, the Navy began emphasizing airborne mine countermeasures 
instead. (After Mine Warfare History, 2003) 

Mines are relatively inexpensive, easy to procure, are difficult to track, and have a highly 
favorable return on investment. In addition, they are certain to play an important role in future 
engagements, especially in joint littoral warfare. Despite all of this, the United States Navy has 
devoted comparatively fewer resources to the development of mine warfare. (Mine Warfare 
History, 2003) 

C. MINE WARFARE 


Mine warfare (MIW) is defined as “the strategic and tactical use of sea mines and their 
countermeasures,” (From Mine Warfare. NWP 3-15. Department of the Navy. August 1999. 1-2) 
and includes offensive, defensive and protective measures for laying and countering sea mines. 

Mine warfare can be broken into two distinct subdivisions - mining and mine countermeasures 
(MCM). Mining encompasses designing, producing, laying mines, while mine countermeasures 
covers the efforts of designing, producing and operating all forms of MCM equipment. (After 
Mine Warfare. 1-2) 

D. MINING 
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Figure 3. Mine Warfare Areas of Operation (From Marshall, Lehr, 1998) 
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For purposes of mine warfare, the littorals are broken down into several areas of 
operation. The area closest to the shoreline, called the surf zone or the coastal landing zone 
(CLZ), extends from water zero to ten feet deep. Typically, obstacles and anti-invasion mines are 
placed in this zone, as well as bottom, moored, and floating mines. The next zone is the very 
shallow water area, and covers water depths from 10 to 40 feet. The shallow water area covers 
40 to 200 feet, and deep water extends to water greater than 200 feet deep. These last three areas 
typically contain buried or partially buried bottom mines, moored, floating, and rising mines. 

These areas can be seen in Figure 3. 

Mining operations support the task of estabhshing and maintaining control of sea areas 
by using naval mines to i nfli ct damage on enemy shipping and/or hinder, dismpt, and deny 
enemy sea operations. Mining operations have an advantage over other naval operations, because 
a minefield can i nfli ct major long-term damage, without allowing for retahatory action against 
the mine-laying force. In addition, a mine is armed 24 hours a day, from the time it is armed, 
until it is countered, or its useful fife expires. (After Mine Warfare. 1-2) 

Other advantages of mines include their covertness and surprise, their psychological 
effect on an enemy, and their abihty to act as a force multipher. In addition, the mine might be 
the only weapon that can apparently alter geography, as an area that has been mined must be 
avoided as if it were land. Finally, aU of these advantages can be effective, even if the use of the 
mine is only simulated or threatened. The actual detonation of the mine might not be a 
significant factor in the effectiveness of the mines. (After Mine Warfare. 2-1) 



Figure 4. Confederate torpedo waiting for a target. (From Naval Mine History [AMCM]) 
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A mine’s passive nature produces most of its advantages, but also is its primary 
weakness. A mine must wait for a target and once laid, it does not discriminate. The stationary 
mine gives the target an opportunity to detect and then avoid or counter the minefield. Other 
disadvantages of mining include material degradation of the mine, and battery sensitivity to 
temperature. Another disadvantage of mining is the depth restrictions on where mines can be 
laid. (After Mine Warfare. 2-1) 

E. MINE COUNTERMEASURES 



Figure 5. USS AVENGER class Mine Countermeasures Ship (Erom USS AVENGER MCM 1) 
MCM are classified as either defensive (enabling) or offensive (proactive). Offensive 
MCM are intended to prevent mines from being laid, and they e lim inate the need for defensive 
MCM. Defensive MCM are classified as passive, preventing interaction between a mine and 
target, or active, which is reactive and involves interfacing directly with mines. (After Mine 
Warfare 3-1) 

Offensive MCM intends to render ineffective one or more links in the mine laying 
process. Offensive MCM can be accomphshed by destroying or disabling mines before they can 
be laid, destroying the enemy’s mine laying capabihty, or mining to trap the enemy’s ships in 
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port. Offensive MCM operations can be executed by strike or special operations forces, which 
have the capabihty of dehvering an attack. (After Mine Warfare. 3-1) 

Unlike offensive MCM, the objective of defensive MCM is to reduce the effectiveness of 
existing minefields. Defensive MCM is divided into active and passive MCM. Passive MCM can 
be divided into three categories. The first category is locating the threat through long-term 
inteUigence collection, increased surveillance, and reconnaissance. After the threat is located, it 
must be localized. Localizing the threat means reducing the area in which shipping may be 
exposed to mines. The final category of passive MCM is reducing the risk. The primary means of 
reducing the risk for MCM forces are practicing precise navigation and influence signature 
control. (After Mine Warfare. 3-3) 



Figure 6. USS RAVEN (MHC 61) Osprey Class. (From Navy Fact File: Coastal Mine Hunters, 

June 2003) 

Active defensive MCM reduce the effectiveness of minefields by removing mines, 
destroying them in place, or neutralizing them. Active MCM includes mine hunting and 
minesweeping. Mine hunting is determining the location of mine in order to avoid, remove, 
render harmless, or destroy each mine. Mine hunting can be acoustic, magnetic, or optical; 
aircraft radar has also been used, but it has not produced dependable results. Minesweeping uses 
mechanical, magnetic, influence, or acoustic sweeps to cut the mooring cable of the mine or to 
actuate the mine. General MCM procedure is to mine hunt when environmental conditions 
permit and minesweep when mine hunting is not possible. This is because mine hunting in a 
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favorable environment is much safer for MCM assets than minesweeping. (After Mine Warfare. 
3-5-3-7) 



Figure 7. AN/SLQ-48 Mine Neutrahzation System (From AN/SLQ-48 Mine Neutrahzation 

System, 2003) 

After a mine is located through mine hunting or minesweeping, it must be neutralized or 
countermined. One way to accomphsh countermining is to use an explosive charge to cause the 
mine to detonate. A disadvantage of this is the requirement of a large explosive charge and/or 
closer placement to the mine, which may involve higher risk to the diver, ROV, or AUV. 
Alternatively, neutrahzation uses an explosive charge to damage the mine mechanism or mpture 
and flood the mine case. The major disadvantage of mine neutralization is that the mine case 
stays on the bottom without detonating the explosives. Other options include removal, which is 
relocation of a mine to an area where it poses no hazard and can be countermined or neutra liz ed 
at a later time, or recovery, for the benefit of exploitation and analysis. (After Mine Warfare. 3- 
14-3-15) 
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F. SUMMARY 

Mine warfare began in the 1700’s with the use of ‘torpedoes’ that floated, waiting to be 
struck by a passing ship. Since then, advancements have been made in the mining area of mine 
warfare, but httle has been done to improve mine countermeasures. Offensive mine 
countermeasures usually involve the destmction of a link in the enemy’s mine-laying 
capabihties, while defensive mine countermeasures usually reduce the effectiveness of a 
minefield. While mine warfare has begun to improve in the last several decades, any type of 
mine neutra liz ation stiU requires the involvement of either an expensive piece of equipment or an 
Explosive Ordnance Disposal (EOD) Officer. 
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m. AUTONOMOUS UNDERWATER VEHICLES (AUVs) 


A. INTRODUCTION 

Unmanned Underwater Vehicles (UUVs) are rapidly becoming a key player in the 
battlespace. With increasing littoral threats, autonomous underwater vehicles provide a capable 
option for meeting the Navy’s needs. There are hundreds of UUVs and AUVs under 
development or commercially available, yet the fleet has tittle UUV based technology. Based on 
the pace of technology in the year 2000, a study team at Space and Naval Warfare Systems 
Center developed a vision of battlefield dominance via unmanned systems 50 years from now. 
Six years earlier, in the 1994 UUV Master Plan, four priorities were established: 

1. “Near-term stopgap mine reconnaissance capability 

2. Greatly improved, higher-performance mine reconnaissance capability 

3. Survetilance, intelligence collection, and tactical oceanography capability 

4. Research and development of enabling technologies for future UUV missions.” 

(From Fletcher, 2000) 

From this list of priorities, the Near-Term Mine Reconnaissance System and the Long- 
Term Mine Reconnaissance Systems evolved. 
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Figure 8. UUV Master Plan Summary Road Map (From Fletcher, 2000) 

“Effective use of UUVs requires both appropriate technology and sound 

engineering.”(From Fletcher, 2000) Technologies to be developed include autonomy, 

communications and sensors. The major focus of this thesis is on the development of increased 

communications among autonomous underwater vehicles (AUVs). Communications for any 
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single AUV or UUV is not a major problem, as the major concerns include available bandwidth, 
range, and covertness. However, communications among multiple vehicles operating together 
pose a much bigger challenge. (After Fletcher 2000) Currently, multiple AUVs are under 
development. Independently, each AUV is quite beneficial to the user, as a means of performing 
missions such as maritime reconnaissance, undersea search and survey, and 
communications/navigation aids to submarine track and trad. (After Whitman, 2002) Being able 
to task various AUVs using a common mission planning language greatly increases the benefit of 
AUVs. 

B. LONG-TERM MINE RECONNAISSANCE SYSTEM (LMRS) 



Figure 9. Long Term Mine Reconnaissance System (LMRS) (From Long Term Mine 

Reconnaissance System (Web)) 

The LMRS evolved from the second priority of the 1994 UUV Program Plan: “Greatly 
improved mine reconnaissance capabdity.” (From Fletcher, 2000) In October 1999, a four-year 
development contract was awarded for initial operational capability in 2003. (After Fletcher, 

2000) The LMRS is a UUV system capable of being launched clandestinely from a SSN688/688I 
or NSSN class submarine. (After Long-Term Mine Reconnaissance System (LMRS)) The 
system consists of a 21-inch diameter autonomous vehicle that would be stowed in the 
submarine’s torpedo room, and could be launched and recovered through the torpedo 
tubes.(After LMRS ORD) Each vehicle was designed with forward and side-looking mine 
detection and classification sonar, as wed as a homing/docking sonar. (After Long Term Mine 
Reconnaissance System) 
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c. 


REMOTE MINEHUNTING SYSTEM (RMS) 



Figure 10. ANAVLD-1 Remote Minehunting System (RMS) (From RMS Broehure) 

A second UUV is the Remote Minehunting System (RMS), “an organic, off-board system 
that will be launched, operated, and recovered from a host surface ship and will employ mine 
reconnaissance sensors.” (From ANAVLD-1 Remote Minehunting System (Web)) RMS is 
intended for use in meeting the demand for over-the-horizon mine reconnaissance in support of 
an individual ship’s mission, and also to prepare for the arrival of follow-on forces. The RMS 
will be used for reconnaissance against bottom and moored mines in deep water to a portion of 
the very shallow water.(From ANAVLD-1 Remote Minehunting System (Web)) The RMS will 
be operated and maintained by a surface ship, but will have self-contained command/control, 
propulsion, power, and navigational capabUities. (From ANAVLD-1 Remote Minehunting 
System (Web)) 

D. BATTLESPACE PREPARATION AUTONOMOUS UNDERWATER VEHICLE 
(BPAUV) 

The BPAUV is a “small, fast underwater robot that maps the ocean bottom near the 
shore, detects changes in inshore conditions, and hints mines.” (From NPS/CIRPAS Activity 
Statement, 2001) Because it is a larger unit, it is able to survey waters up to 300 meters deep, and 
conduct mine-hunting missions, and wide-area bottom mapping. (After Rose, 2002) However, 
because Bluefin Robotics Corp developed the BPAUV commercially, elements such as the 
source code are proprietary and may not be changed by any other company to provide new 
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functionality. (After Naval Coastal Sea Systems) This dilemma begins to introduce the need for 
creating a common mission and data formatting language for autonomous underwater vehicles 
using non-proprietary XML. 

E. REMOTE ENVIRONMENTAL MONITORING UNITS (REMUS) 

The REMUS is a low-cost AUV developed by and commercially available from the 
Oceanographic Systems Laboratory at Woods Hole Oceanographic Institute for coastal 
monitoring and multi-vehicle survey operations. (After WHOI at Sea) REMUS operates in depths 
from 10 to 66 feet and can be deployed by one or two men from a small craft without hoists. 
Another selling point of the REMUS is that data is downloadable into MEDAL format. (After 
Commerce Business Daily, 2001) Like the BPAUV, REMUS was developed commercially, and 
aU source code is proprietary. Therefore, no other company can design and implement changes to 
the source code. 



Eigure 11. REMUS Variants “Darter,” “CrevaUe:” and “Gudgeon” (left to right) (Weekley, 2003) 

F. AUV RESEARCH AT THE NAVAL POSTGRADUATE SCHOOL 


The Naval Postgraduate School’s (NPS) Center for AUV Research began in 1987, as a 
combined effort of the Departments of Mechanical Engineering, Computer Science, and 
Electrical and Computer Engineering. The Navy’s interest in developing underwater vehicles for 
use in clandestine mine operations was very influential in the forming of the center. The Office 
of Naval Research sponsors most of the research performed by the Center, in collaboration with 
the Elorida Atlantic University, with other funding coming from the National Science 
Eoundation and the Naval Explosive Ordnance Disposal (EOD) Technical Head. The Center has 
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developed and tested three AUVs. The NPS AUVI and PHOENIX AUV are no longer in use by 
the Center, as the multi vehicle network server Acoustic Radio Information Exchange Server 
(ARIES) is currently operational in the Monterey Bay. In addition to ARIES, NPS has recently 
acquired the commercially built REMUS for other research. 

The ARIES has been a test-bed for “development and evaluation of non-linear and 
adaptive control of vehicle motion. It has supported experimental work in system identification, 
and the development of high-speed graphics based physical modeling.” (After NPS Center for 
AUV Research, June 2003) Numerous graduate and doctoral students have worked with ARIES 
as a communications server vehicle. The vehicle is also being used to develop low cost 
underwater navigation capabilities using commercial off the shelf (COTS) systems. 



Eigure 12. NPS ARIES on Deployment (Erom NPS Center for AUV Research, June 2003) 

G. SUMMARY 

Most existing and emerging AUVs are commercially developed, and thus contain 
proprietary information. One of the biggest challenges facing the Navy’s use of AUVs is the 
abUity of the vehicle to communicate with others and to interface with the GCCS-MEDAE 
system, which will be discussed further in Chapter 7. The lack of a common language creates a 
barrier between vehicles, and makes command and control of the AUVs more difficult. 
Restricting development by imposing a common language requirement is neither feasible nor 
cost-effective. At this point, XML appears to be the best option for creating a common mission 
and data scripting language for AUVs. By DoD directive, the use of XML must be non¬ 
proprietary, which would eliminate the need to always return to the developer when changes 
must be made. 
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IV. INTRODUCTION TO XML AND XSLT 


A. INTRODUCTION 

To begin a discussion about Extensible Markup Language (XML), one must talk about 
the World Wide Web Consortium (W3C). “The World Wide Web Consortium was created in 
October 1994 to lead the World Wide Web to its full potential by developing common protocols 
that promote its evolution and ensure its interoperability.” (After W3C, 2003) It does this by 
developing technologies, specifications, guidelines, software, and tools that will create a fomm 
for information, commerce, inspiration, independent thought, and collective understanding. The 
design goals for XML are shown in the table below. 

1. XML shall be straightforwardly usable over the Internet. 

2. XML shall support a wide variety of applications. 

3. XML shall be compatible with SGML. 

4. It shall be easy to write programs that process XML documents. 

5. The number of optional features in XML is to be kept to the absolute minimum, ideally zero. 

6. XML documents should be humanly legible and reasonably clear. 

7. The XML design should be prepared quickly. 

8. The design of XML shall be formal and concise. 

9. XML documents shall be easy to create. 

10. Terseness in XML markup is of minimal importance. 

Table 1 XML Design Goals (After W3C, 2003) 

Before XML, there was Standard Generahzed Markup Language (SGML). “SGML is a 
meta language (i.e., a language for creating other languages) that is used to create markup 
languages, such as Hypertext Markup Language (HTML).” (Lrom Deitel, Deitel, Nieto, Lin, and 
Sadhu, 2001) 
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B. EXTENSIBLE MARKUP LANGUAGE (XML) 


A Working Group of twelve professionals with significant shared experience, both with 
the World Wide Web and with using computers to process and manage information using SGML 
came together. The Web was growing exponentially and they wanted to use it to pubhsh their 
SGML-encoded information. Although SGML was a ten-year-old technology, it was very 
powerful and it made information reusable. It had the ability to describe information in a way 
that was system-independent. But SGML had its problems; it was difficult to learn, its 
acceptance was l im ited to documentation professionals, and it was very difficult to use SGML 
with this new medium known as the Web. The group formed around the idea that the two 
technologies could be made to work together to make it easier to share and reuse information. 
(After Berners-Lee with Fischetti, 1999) 

Working under the auspices of the W3C, they embarked on a journey to create this 
nameless subset of SGML which would make it easy to use on the Internet, support a wide 
variety of apphcations, be compatible with SGML, and, ultimately, change the world. The goal 
of bringing together the two powerful ideas of the Web and of descriptive markup energized the 
group and drove them to work evenings and meeting by teleconference. Whenever we lost our 
way, someone would ask, “Is this feature necessary for success?” The group worked to transform 
these goals and experiences into a formal language, a language designed to make sharing 
reusable information ubiquitous. This became known as XML. 

<scene> 

<FX>General Road Building noises.</FX> 

<speech speaker="Prosser"> 

Come off it Mr Dent, you can't win 
you know. There's no point in lying 
down in the path of progress. 

</speech> 

<speech speaker="Arthur"> 

I've gone off the idea of progress. 

It's overrated 
</speech> 

</scene> 

Figure 13. Sample XML file (From ‘What is XSL?’ 2003) 

The group knew SGML was the best approach for reusing the kin ds of information they 
worked with, but they needed to make SGML easier to learn, understand, and implement, while 
retaining its core values, “SGML fit for the Web.” The core value of SGML that they wanted to 
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build into XML was that of “descriptive markup." “Markup is information inserted into a 
document that computers use; in the case of SGML, markup takes the form of tags inserted into 
documents to mark their stmcture. Descriptive markup uses markup to label the stmcture and 
other properties of information in a way that is independent of both the system if s created on and 
of the processing to be performed on it.” (From Hollander and Sperberg-McQueen 2003) 



♦ XML Kasuhaf of SGWl 

♦ HTML «tc me afff(iat>afK of 

♦ XHTML etc art 4^rdtrom of XML 

♦ RDF II an of XML 

♦ ncs. PBPctc ara^A:alron< of RCf 

Figure 14. SGML - XML Relationship (From Just what is XML? June 2003) 

They wanted XML, like SGML, to be a meta-language. They wanted it to create 
vocabularies that is relevant to their information and to enable user-defined, processing- 
independent markup that are easier to reuse and can be processed in new and often unexpected 
ways. 

SGML, fit for the Web, would make it easy and rehable for computers (and humans) to 
use descriptive, stmctural markup in their documents. By using descriptive data tags, the 
information owner can make documents into semantically rich data and avoid what they called 
“cmfty tag salad”, presentation-oriented markup used just because it looks right. 

The result was a 25-page XML specification that could be easily learned and 
implemented. XML, a meta-language that allows design markup languages that describes what is 
important to the user. It provides elements and attributes to capture logical structure and enables 
semantic understanding. They were able to balance features against complexity. Their practical 
litmus test “is it necessary for success?” helped us create a language fit for the Web. 
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A data object is an XML document if it is well formed, and may also be valid if it meets 
certain constraints. Well-formed documents do not have to be created in a stmctured 
environment, ag^nst a pre-defined set of stmctural mles, but merely have to comply with XML 
well-formedness constraints. Well-formed XML elements are defined by their use, allowing 
authors to tailor elements to their development. This flexibihty gives authors greater control over 
document processing and design. This is a great improvement over traditional SGML 
environments, in which stmcture must be formally defined before any documents can be written. 
C. XML SCHEMAS 

A schema is a set of mles that a document follows, which software may need to read 
before processing and displaying a document. Vahd XML differs form well formed XML in its 
relationship to a schema. Well-formed XML is designed for use without a schema, whereas vahd 
XML exphcitly requires it. Table 1 fists everything that a schema can be used to define. 

1. Elements that can appear in a document. 

2. Attributes that can appear in a document. 

3. Which elements are child elements. 

4. The order of child elements. 

5. The number of child elements. 

6. Whether an element is empty or can include text. 

7. Data types for elements and attributes. 

8. Default and fixed values for elements and attributes. 

Table 2 Schema Definitions (After Introduction to XML Schema) 

Once written, a schema allows the user to check whether an XML document is valid. 
Valid XML documents employ features that can significantly improve the usability of a 
document, including: finking mechanisms, entities and attributes. Most XML Web sites are 
fikely to be composed of valid XML documents. Using a schema gives creators the freedom to 
stmcture their sites and use much greater feature sets than HTML has traditionally allowed. The 
process for validating a schema is shown in Figure 15. 
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Valid 

Or 

Not? 


Figure 15. XML Schema Validation Process (From Serin, 2003) 

“Document authoring, processing, storage and display are made easier because 
documents exist in a stmctured environment. Authors must create documents against a pre¬ 
defined stmcture and benefit from a clear document model. Like well-formed XML, valid 
documents must be accompanied by stylesheets to achieve visual display.” (From Vahd XML) 

The original group of twelve with its common, shared experience gave way to lots of 
groups with differing goals and backgrounds. XML grew stronger for the new insights. You now 
have XML -i- XLINK -i- XSL -i- Namespaces -i- Infoset -i- XML Linking -i- XPointer Framework -i- 
XPointer namespaces -i- XPointer xptr() -i- XSLT -i- XPath -i- XSL FO -i- DOM -i- Sax -i- stylesheet 
linking PI -i- XML Schema -i- XQuery -i- XML Encryption -i- XML Canonicahzation -i- XML 
Signature -i- DOM Level 2 -i- DOM Level 3. 

D. EXTENSffiLE STYLESHEET LANGUAGE FOR TRANSFORMATIONS (XSLT) 

One of the tools mentioned above, which is pertinent to this thesis, is Extensible 
Stylesheet Eanguage (XSE). XSE is a language for expressing style sheets. It is made up of three 
components: 

1. XSE Transformations (XSET), a language for transforming XML documents 

2. XML Path Language (XPath), an expression language used by XSLT to access or refer to 
parts of an XML document 

3. XSL Eormatting Objects (XSL-EO), an XML vocabulary for specifying formatting 
semantics 

An XSL style sheet is, like with Cascading Style Sheets (CSS), a file that describes how 
to display an XML document of a given type. XSL shares the functionahty and is compatible 
with Cascading Style Sheets, level 2 (CSS2), a style sheet language that allows authors and users 
to attach style (e.g., fonts, spacing, and aural cues) to stmctured documents (e.g., HTML 
documents and XML apphcations), although it uses a different syntax. It also adds: 
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• A transformation language for XML documents: XSLT. Originally intended to 
perform complex styling operations, tike the generation of tables of contents and 
indexes, it is now used as a general purpose XML processing language. XSLT is 
thus widely used for purposes other than XSL, tike generating HTML web pages 
from XML data. 

• Advanced styling features, expressed by an XML document type which defines a 
set of elements called Formatting Objects, and attributes (in part borrowed from 
CSS2 properties and adding more complex ones (After The Extensible Stylesheet 
Language) 

Styling requires a source XML documents and a style sheet. The source document 
contains the information the style sheet will display while the style sheet describes how to 
display a document of a given type. Figures xmll, xml2, and xmlS show a sample XML file, two 
sample templates from a style sheet and the rendering of them, respectively. 

Separating the source documenf s content and its styling information allows displaying 
the same document on different media (tike screen, paper, cell phone), and it also enables users 
to view the document according to their preferences and abilities, just by modifying the style 
sheet. 

<xsl:template match="FX"> 

<fo:block font-weight="bold"> 

<xsl:apply- templates/> 

</fo:block> 

</xsl:template> 

<xsl:template match="speech[ @ speakei^'Arthur'] "> 

<fo:block background- color="blue"> 

<xsl:value-of select="@speaker"/>: 

<xsl:apply- templates/> 

</fo:block> 

</xsl:template> 

Figure 16. Sample XSFT (From What is XSF?) 

The style sheet can be used to transform any instance of the schema/Document Type 
Declaration (DTD) it was designed for. “The first mle says that an FX element will be 
transformed into a block with a bold font. <xsl:apply-templates/> is a recursive call to the 
template mles for the contents of the current element. The second template applies to aU speech 
elements that have the speaker attribute set to Arthur, and formats them as blue blocks within 
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which the value speaker attribute is added before the text. (After The Extensible Stylesheet 
Language) 


General Road Building noises. 

Prosser: Come off it Mr. Dent, you can't win you know. There's no point in iying down in the path 
of progress. 

Arthur: I’ve gone off the idea of progress. It’s overrated _ 

Figure 17. Sample Output (From What is XSL?) 

The above rendering is the Formatting Objects (XSL-FO) generated by the XML file and 
two sample templates from a style sheet. The XSL-FO vocabulary is designed to allow 
information to be displayed on a wide variety of media: screen, paper, or even voice. 

E. SUMMARY 

In this chapter XML and XSLT are discussed. The roots of XML are given, XSLT is 
briefly expounded on, and some other related technologies are mentioned to provide the 
background and basis upon which this common data and formatting language will be built. 
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V. USING XML AND XSLT TO INCREASE AUV INTEROPERABILITY 


A. INTRODUCTION 

Twenty years ago, software only worked with other software bought from the same 
vendor. Today, consumers rightly expect software components to be interchangeable. The W3C, 
a vendor-neutral organization promotes interoperability by designing non-proprietary computer 
languages and protocols to avoid the market fragmentation of the past. (From W3C in 7 Points) 

B. XML AND INTEROPERABILITY 

As stated in Chapter HI, at least four different AUVs either exist or are under 
development: one for each area of operation. Hydroid, Inc. manufactures REMUS (After 
Hydroid, Inc), Bluefin Robotics manufactures BPAUV (After ONR BPAUV). Lockheed Martin 
has the contract for RMS and Boeing has LMRS. Interoperabihty is defined as the ability of 
systems, units, or forces to provide services to and accept services from other systems, units, or 
forces and to use the services so exchanged to enable them to operate effectively together. (After 
Defense Technical Information Center) Currently, most AUVs are commercially developed, 
contain proprietary internal architectures, and, thus display poor interoperabihty. 



Figure 18. XML Interoperabihty (After Wrox Diagram) 

One method of improving interoperabihty is through the use of a common XML-based 
mission planning and data formatting language. Similar XML-based languages have already 
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been used in various applications to achieve software interoperability. For example, the Schools 
Interoperability Framework, a division of the Software and Information Industry Association 
demonstrated interoperable applications in November 2001. The software interoperability was 
exhibited in a network environment, in which data is shared between applications through a 
“series of standard messages, queries, and events written in XML.” (From Schools 
Interoperability Framework, June 2003) 

Numerous other examples of the use of XML to increase software interoperabihty exist. 
The IMS Global Learning Consortium uses XML binding because of its ease of maintainabihty 
and increased flexibihty. (After IMS Global Learning Consortium) The Open Travel AUiance 
(OTA) formed to “improve the electronic exchange of business information across aU sectors of 
the travel industry .’’(From OTA XML Specification, June 2003) To assist programmers with the 
implementation of a cross-industry effort to improve this exchange, OTA released a 
Specification Document, a schema and schema fragments, a Document Type Definition (DTD), 
a Universal Modehng Language (UML) Model, a Data Dictionary, and Appendices. (After OTA 
XML Specification, June 2003) The retail industry has joined the XML drive, with the 
International XML Retail Cooperative (After IXRetail), which is intended to ease apphcation-to- 
apphcation integration within a retail enterprise. The IXRetail initiative began in 2000, when the 
Lim ited began looking at XML for apphcation integration. The Lim ited concluded that XML 
could be used for apphcation-to-apphcation integration within the enterprise, apphcation 
constmction and evolution of the Enterprise Apphcation Integration (EAI).(After ARTS/KRetail 
XME Event, June 2003) EinaUy, the health care industry is joining the push towards the use of 
XME, as well, with the HE7/XME Interface. Health Eevel 7 (HE7) is “the dominant health care 
standards organization for healthcare message communication from machine to machine in the 
United States, with an active presence in Europe, Austraha, and most recently in Japan.” HE7 
used XME for both healthcare messages and chnical record documents, and represented the 
culmination of three years of work in bringing together the HE7 communication protocol with 
the XME markup strategy. (After H17-XME Progress Report, June 2003) 

As evidenced by the above examples, XME is becoming a common answer to the 

interoperabihty problems faced by any industry. This is because XME is designed with the 

abUity to describe information in a way that is system-independent. In addition to being 

relatively simple to write, a user can easily export an XME document to both XME and non- 
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XML formats. XML also makes archive maintenance easier, as wiU be addressed in a later 
chapter. XML documents can be accessed via an http server. Finally, in root form, XML is 
transferable on the fly by stylesheet. Thus XML and related technologies can be used to improve 
interoperabihty between AUVs. 

C. CONSTRUCTING THE MISSION COMMAND LANGUAGE 

The first step in constmcting a Common XML-Based Mission and Data Formatting 
Language using XML is defining a tag set. A tag set is the set elements and attributes use to 
describe what is trying to communicated or described. To make a language common and 
interoperable, tags must come from a central XML registry that allows common access. XML 
registries are a vital component in the implementation of shared data exchanges. The DoD XML 
Registry constitutes guidance in the generation and use of XML among DoD communities of 
interest and is the authoritative source for registered XML data and metadata components. 

Researching the DoD XML Registry resulted in the rea liz ation that only some of the 
necessary tags for a common mission and data formatting language exist. One output of this 
thesis is a proposed AUV Namespace. (See Appendix E) “Namespaces are technical mechanisms 
that allows overlapping XML to be tagged with distinguishing labels.” (From DoD Metadata 
Registry and Clearinghouse) Namespaces make up collections of data constmcts that share a 
common context within a Community of Interest (COI) that can be leveraged for XML 
administrative purposes. A COI is a group of people, agencies, activities, and system builders 
who share an interest in a specific domain. 

After defining the tagset, the XML schema document can be written. The schema 
document is the modehng document, which defines the stmcture of the input XML documents. 

The schema is used to validate these documents and uses the same syntax that XML uses; while 
fuUy supporting the Namespace Recommendation. In addition, the schema allows creation of 
complex and reusable content models with the idea of object inheritance and type substitution. 

The fundamental idea behind vahdation is to create XML documents that they can be shared by 
multiple users without any conflict when they follow the same mles that the schema defines. Any 
well-formed XML document can be vahdated against any schema. (After Serin, 2003). Using the 
schema document as a guide, an XSLT is written to transform some input into a user-defined 
output. Examples of those outputs are illustrated in the next chapter. 
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D. TRANSFORMING THE DOCUMENT 


XSLT stylesheets use XML Path Language to match nodes when transforming an XML 
document. Xpath provides syntax for locating specific parts of an XML document. Once Xpath 
has located and matched a node, an XSLT Processor can transform the document into another 
form, whether it is XML, HTML, plain text, or any other text-based document. (Deitel, Deitel, 
Neito, Lin, and Sadhu, 2001) One benefit of using XSLT for such a task is that XSLT has none 
of the ‘side effects’ of correct order and code mnning the way it is written. XSLT, on the other 
hand, will mn correctly, regardless of the order in which tasks are performed. In addition, an 
XSLT engine can mn the code in a stylesheet in any order. Because XLST is a declarative 
language, rather than an imperative one, it can even mn multiple pieces of code simultaneously, 
effectively optimizing the program. A visual representation of the stylesheet function is shown 
below. 



Figure 19. Demonstration of XSLT Functions (From XML - An Introduction, June 2003) 

E. ARCHIVING XML DATA 

Digital pubhcation preservation is a significant part of tomorrow’s heritage. Without a 

concerted effort, the digital information of today will not be available. By correctly archiving 

data, especially the data collected from AUV missions, MEDAL, and other similar databases 
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continue to be able to access this data. XML documents can be archived wither of two places, on 
the file system itself or in a database. While the file system is fast and simple, it is not really 
practical for large apphcations, so the logical choice is to archive data in a database. There are 
two types of databases. First there is a Relational Database Management System (RDBMS), 
which offers many advantages such as tools for data mining, but at the expense of needing 
transformations into a relational data model and translations for queries. Another option is the 
use of Native XML databases, which have much better performance for storage, retrieval, and 
query, but lack the advantages of a mature RDBMS product. 



Figure 20. XML Archiving Process (From Ipedo Web, June 2003) 

F. SUMMARY 

This chapter discussed the use of XML and related technologies for increasing the 
interoperabihty of software in various industries, including retail, healthcare, and online learning. 
Throughout the development of this thesis, the DoD XML Registry was searched for apphcable 
tags to define an AUV Namespace. Because most of the necessary tags are not currently in use, a 
proposed AUV Namespace was developed, and can be seen in Appendix F. After developing a 
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tagset, a schema document was developed to validate the mission documents. Finally, as a 
experimental test, an XSLT template was developed to transform the XML mission document 
into a text-based file. 
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VI. AUV SIMULATION WORKBENCH 


A. INTRODUCTION 

This chapter describes the AUV Workbench and gives a sample mission document. An AUV 
Workbench mission script file is presented first. This script file is incorporated into the mission 
command language to show the capability to output data that can be use by the AUV 
Workbench. 


B. AUV WORKBENCH OVERVIEW 

The AUV Workbench is used by the scripts developers and by the thesis students to test 
and edit their simulations. It will also allow for the pre- visu aliza tion of in-water missions. It is 
designed to: 

- Simphfy and make more easily the utilization of the simulation 

- Have aU the windows in one main window 

- Allow scripts developers to edit and test their scripts more quickly 

- Allow AUV software developers to evaluate execution and dynamics improvements 
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Figure 21. Interface of AUV Workbench (Gruneisen and Henriet, 2002) 


The Mission Script Editor is a text editor with which users can create, open or save 
missions. When a mission is opened, the software automatically creates a backup of this file 
(with the name of the mission and the date). So, the user can reopen this file in case of a 
modification error. The mission opened will be the mission used for the simulation. 

The Execution and Dynamics panels allow the user to launch or stop the simulation of the 
Mission Eile in the Mission Editor. They allow the user to display the simulation in real-time or 
not, clear the execution and dynamics text area and save the execution and dynamics text area in 
two different files, MissionName_Execution_Date and MissionName_Dynamics_Date, 
respectively. 
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The Options Panel allows the user to select Execution Program: there are two different 
programs for the execution level (one in C and the other in Java), so the users can select which 
one to use; and select AUV Model: there are four different AUVs which each have different 
dynamics coefficients, so the users can select which coefficients they want to use for the 
simulation. 

The simulation process works be means of the Java language that allows developers to 
execute others programs from a Java program. Here, there are two different Threads (one for 
Execution and one for Dynamics) which have launch the programs, catch the output streams, and 
print them in the two text areas in the main window. 

The Extensible Java 3D Graphics (Xj3D) apphcation programming interface (API) and 
veiwer uses all the specification of Extensible 3D Graphics ^3D) to be able to display a Virtual 
Reahty Modeling I^anguage (VRME) file in a program using Java3D. “However, Xj3D is 
currently under development, so not all of the X3D nodes are integrated in Xj3D (Billboard for 
example); thus, it is necessary for the users to download and install the latest version of the Xj3D 
package to update the Java classes which are used by the program.” (After Gmneisen and 
Henriet, 2002) 

C. DESCRIPTION OF USE (F TAGSET AND SCHEMA IN CONJUNCTION WITH 
THE AUV WORKBENCH 

Below is an inclusive tag set based on the AUV mission script help file and the AUV 
Workbench. 


<?xml version="1.0" encoding="UTF-8" ?> 

- <!— Sample XML file generated by XMLSPY v5 U (http://www.xmlspy.com) —> 

- <AUVMission xmlns;xsi="http ://www.w3.org/2001/XMLSchema-instance" 

xsi : noNamespaceSchemaLocation="C : \Dociiments and 

Settings\dlhawkin\Desktop\AUVMission.xsd"> 

<Prof ile>Text</Prof ile> 

<InsertPoint Xcoordinate="5000" Ycoordinate="5000" Zcoordinate="164" /> 

<Waypoints number="0" Xcoordinate="5000" Ycoordinate="5000" 

Zcoordinate="164" /> 

<StarboardPropSpeed>3820</StarboardPropSpeed> 

<PortPropSpeed>3820</PortPropSpeed> 

<Thrusters>l</Thrusters> 

<Rudder >90< /Rudder > 

<ChangeCourse>359.9</ChangeCourse> 

<PlanesAngle stern="90" bow="90" both="90" /> 

<CommandedAltitude Zcoordinate="164" /> 

<CommandedDepth Zcoordinate="164" /> 

<PitchAngle>30</PitchAngle> 

<Theta>30</Theta> 

<Rotate>40</Rotate> 

<Lateral>0.82</Lateral> 

<DiveTracker Xcoordinate="5000" Ycoordinate="5000" Zcoordinate="164" /> 
<AltitudeOrDepthControl>l</AltitudeOrDepthControl> 
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<Perf ormGPSPopup>l</PerformGPSPopup> 
<DurationGPSPopup>1000</DurationGPSPopup> 

<GyroError>180</GyroError> 

<DepthCellError>100</DepthCellError> 

<Position Xcoordinate="5000" Ycoordinate="5000" Zcoordinate="164" /> 
<Orientation phi="30" theta="30" psi="359.9" /> 

<Posture Xcoordinate="5000" Ycoordinate="5000" Zcoordinate="164" phi="30" 
theta="30" psi="359.9" /> 

<OceanCurrent xAxis="50" yAxis="50" zAxis="50" /> 

<SeaState>9</ SeaState> 

<WatchRadius>10000</WatchRadius> 

<WaypointTimeout>1000< /WaypointTimeout > 

<StandOffoist ance>100</ StandOffoistance> 

<Hover enabled="l" Xcoordinate="5000" Ycoordinate="5000" Zcoordinate=" 164 " 

/> 

<TargetStation rangeToTarget="10000" bearingToTarget="359.9" 

commandedRange=" 10000" commandedHeading="359.9" psi="359.9" /> 
<TargetPoint>l</TargetPoint> 

<EnterTube range="20" bearing="359.9" /> 

<Wait>1000</Wait> 

<WaitUntil>1000</WaitUntil> 

<TimeStep> 1000</ TimeStep> 

<SingleStep>l</ SingleStep> 

<Pause>l</Pause> 

<RealTime>l</RealTime> 

<Virtual>Stringa</Virtual> 

<LocationLab>l</LocationLab> 

<Tethered>l</Tethered> 

<VirtualHost>Stringa</VirtualHost> 

<Mission>String</Mission> 

<Telemetry>String</ Telemetry > 

<NoScript>l</NoScript> 

<Keyboard>l</Keyboard> 

<Trace>l</Trace> 

<TraceOn>l</TraceOn> 

<LoopForever>l</LoopForever> 

<ControlConstantsFilename>String</ControlConstantsFilename> 

<Text>l</Text> 

<Exit>l</Exit> 

- <SonarCommands> 

<Sonar725Installed bearing="90" range="10000" power="50" 

direction="TRUE" /> 

</ SonarCommands > 

<Sound>l</Sound> 

<EMail>l</EMail> 

<SlidingModeCourse>l</ SlidingModeCourse> 
<ParallelPortTrace>l</ParallelPortTrace> 

<ExtractPoint Xcoordinate="5000" Ycoordinate="5000" Zcoordinate="164" /> 
</AUVMission> 


Below is a sample mission script file for the AUV Workbench. 


<?xml version="1.0" encoding="UTF-8" ?> 

- <!— edited with XMLSPY v5 U (http://www.xmlspy.com) by Oouglas Horner 

(Naval Postgraduate School) —> 

-<AUVMission xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 

xsi : noNamespaceSchemaLocation= 

"C :/AUVWorkbench/bin/scripts/missionScripts/AUVMission.xsd"> 
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- <Profile> 

- <InsertPoint> 

<Xcoordinate>-50</Xcoordinate> 

<Ycoordinate>10</Ycoordinate> 

</ InsertPoint > 

- <WaYpoints number="l"> 
<Xcoordinate>10</Xcoordinate> 
<Ycoordinate>10</Ycoordinate> 

<StarboardPropSpeed>2 . 75</StarboardPropSpeed> 
<PortPropSpeed>2 . 75</PortPropSpeed> 
<AltitudeOrDepthControl>0</AltitudeOrDepthControl> 
<CommandedAltitude>l . 25</CommandedAltitude> 
<CommandedDepth>l .00</ CommandedDepth> 
<PerformGPSPopup>0</PerformGPSPopup> 
<DurationGPSPopup>25</DurationGPSPopup> 
<WatchRadius>8</WatchRadius> 

<WaypointTimeout >40</ WaypointTimeout > 

< /Waypoint s> 

- <Waypoints number="2"> 
<Xcoordinate>10</Xcoordinate> 
<Ycoordinate>210</Ycoordinate> 
<StarboardPropSpeed>2 . 75</StarboardPropSpeed> 
<PortPropSpeed>2 . 75</PortPropSpeed> 
<AltitudeOrDepthControl>0</AltitudeOrDepthControl> 
<CommandedAltitude>l . 25</CommandedAltitude> 
<CommandedDepth>l .00</ CommandedDepth> 
<PerformGPSPopup>0</PerformGPSPopup> 
<DurationGPSPopup>25</DurationGPSPopup> 
<WatchRadius>8</WatchRadius> 

<Waypoint Timeout >2 00</ Waypoint Timeout > 

</Waypoints> 

- <Waypoints number="3"> 
<Xcoordinate>25</Xcoordinate> 
<Ycoordinate>210</Ycoordinate> 
<StarboardPropSpeed>2 . 75</StarboardPropSpeed> 
<PortPropSpeed>2 . 75</PortPropSpeed> 
<AltitudeOrDepthControl>0</AltitudeOrDepthControl> 
<CommandedAltitude>l .25</ CommandedAltitude> 
<CommandedDepth>l .00</ CommandedDepth> 

<Perf ormGPSPopup>0</PerformGPSPopup> 

<DurationGPSPopup>25</DurationGPSPopup> 

<WatchRadius>2</WatchRadius> 

<WaYpointTimeout>15< /WaypointTimeout > 

< /Waypoint s> 

- <Waypoints number="4"> 
<Xcoordinate>25</Xcoordinate> 
<Ycoordinate>10</Ycoordinate> 

<StarboardPropSpeed>2 . 75</StarboardPropSpeed> 
<PortPropSpeed>2 . 75</PortPropSpeed> 
<AltitudeOrDepthControl>0</AltitudeOrDepthControl> 
<CommandedAltitude>l . 25</CommandedAltitude> 
<CommandedDepth>l .00</ CommandedDepth> 
<PerformGPSPopup>0</PerformGPSPopup> 
<DurationGPSPopup>25</DurationGPSPopup> 
<WatchRadius>2</WatchRadius> 

<WaypointTimeout >200</ WaypointTimeout > 

< /Waypoint s> 

- <Waypoints number="5"> 
<Xcoordinate>40</Xcoordinate> 
<Ycoordinate>10</Ycoordinate> 

<StarboardPropSpeed>2 . 75</StarboardPropSpeed> 
<PortPropSpeed>2 . 75</PortPropSpeed> 
<AltitudeOrDepthControl>0</AltitudeOrDepthControl> 
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<ComiiiandedAltitude>l . 2b</ CommandedAltitude> 
<ComniandedDepth>l .00</ CommandedDepth> 

<Perf ormGPSPopup>0</PerformGPSPopup> 

<DurationGPSPopup>25</DurationGPSPopup> 

<WatchRadius>2</WatchRadius> 

<WaYpointTimeout>15< /WaypointTimeout > 

< /Waypoint s> 

- <Waypoints number="6"> 
<Xcoordinate>40</Xcoordinate> 
<Ycoordinate>210</Ycoordinate> 
<StarboardPropSpeed>2 .75</StarboardPropSpeed> 
<PortPropSpeed>2.75</PortPropSpeed> 
<AltitudeOrDepthControl>0</AltitudeOrDepthControl> 
<CommandedAltitude>l .25</CommandedAltitude> 
<CommandedDepth>l .00</ CommandedDepth> 
<PerformGPSPopup>0</PerformGPSPopup> 
<DurationGPSPopup>25</DurationGPSPopup> 
<WatchRadius>2</WatchRadius> 

<WaypointTimeout >200</ WaypointTimeout > 

< /Waypoint s> 

- <Waypoints number="7"> 
<Xcoordinate>41</Xcoordinate> 
<Ycoordinate>210</Ycoordinate> 
<StarboardPropSpeed>2 .75</StarboardPropSpeed> 
<PortPropSpeed>2.75</PortPropSpeed> 
<AltitudeOrDepthControl>0</AltitudeOrDepthControl> 
<CommandedAltitude>l .25</CommandedAltitude> 
<CommandedDepth>l .00</ CommandedDepth> 

<Perf ormGPSPopup>0</PerformGPSPopup> 

<DurationGPSPopup>25</DurationGPSPopup> 

<WatchRadius>2</WatchRadius> 

<WaypointTimeout>l< /WaypointTimeout > 

< /Waypoint s> 

<ExtractPoint /> 

</Profile> 

</AUVMission> 


Based on the mission command language schema document the AUV Workbench input 
file format, below is the XSLT used to create an date file that can be used by the AUV 
Workbench to execute a mission. 


<?xml version="1.0" encoding="UTF-8"?> 

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
xmlns:xsi="http;//www.w3.org/2001/XMLSchema-instance" 
xsi:noNamespaceSchemaLocation="C:\Documents and 
Settings\dlhawkin\Desktop\AUVMission.xsd"> 

<xsl:output media-type="text/html" method="html" indent="yes" doctype-public="- 
//W3C//DTD HTML 4.01//EN" doctype-system="http://www.w3 . org/TR/html4/strict.dtd"/> 
<xsl:template match="/"> 

<! — Number of Waypoints — > 

<xsl:value-of select="count ( //Waypoints)"/> 

<xsl:for-each select="//Waypoints"> 

<br></br> 

<!— Waypoints Xcoordinate — > 

<xsl:value-of select="./Xcoordinate"/> 

<xsl:text> </xsl:text> 

<! — Waypoints Ycoordinate — > 

<xsl:value-of select="./Ycoordinate"/> 

<xsl:text> </xsl:text> 

<! — StarboardPropSpeed — > _ 


38 




<xsl:value-of select="./StarboardPropSpeed"/> 
<xsl:text> </xsl:text> 

<!— PortPropSpeed — > 

<xsl:value-of select="./PortPropSpeed"/> 
<xsl:text> </xsl:text> 

<!— Altitude or DepthControl — > 

<xsl:value-of select="./AltitudeOrDepthControl"/> 
<xsl:text> </xsl:text> 

<!— Commanded Altitude — > 

<xsl:value-of select="./CommandedAltitude"/> 
<xsl:text> </xsl:text> 

< !— Commanded Depth — > 

<xsl:value-of select="./CommandedDepth"/> 
<xsl:text> </xsl:text> 

<!— Perform GPS Popup — > 

<xsl:value-of select="./PerformGPSPopup"/> 
<xsl:text> </xsl:text> 

<!— Duration of GPS Popup — > 

<xsl:value-of select="./DurationGPSPopup"/> 
<xsl:text> </xsl:text> 

<!— Watch Radius — > 

<xsl:value-of select="./WatchRadius"/> 

<xsl:text> </xsl:text> 

<!— Waypoint Timeout — > 

<xsl:value-of select="./WaypointTimeout"/> 

</xsl:for-each> 

</xsl:template> 

</xsl:stylesheet> 


The mission script file is transformed by the XSLT to create the AUV Workbench input file 

below. The input file is in the exact format used by the AUV Workbench. By modifying the 

XSLT, not the AUV software, the user can format the data virtually in any form desired. 

7 

10 10 2.75 2,75 0 1.25 1.00 0 25 8 40 

10 210 2.75 2.75 0 1.25 1.00 0 25 8 200 

25 210 2.75 2.75 0 1.25 1.00 0 25 2 15 

25 10 2.75 2.75 0 1.25 1.00 0 25 2 200 

40 10 2.75 2.75 0 1.25 1.00 0 25 2 15 

40 210 2.75 2.75 0 1.25 1.00 0 25 2 200 

41 210 2.75 2.75 0 1.25 1.00 0 25 2 1 

D. CHAPTER SUMMARY 

Currently, the AUV Workbench is not compatible with aU AUVs. Using the XSL and this 
mission command language, it is possible to generate virtually any type of data file the user 
desires. It follows that development of this language can be the key to the next level of 
commanding aU AUVs. 
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VII. THE BIGGER PICTURE - INTEGRATION OE XML AND 

GCCS/MEDAL 


A. INTRODUCTION 

Currently, the Navy requires that AUVs under development be able to export certain data 
in United States Message Text Format (USMTF). This requirement is so that the data obtained in 
a mission can be uploaded into the GCCS/MEDAL system, for use by all authorized Navy 
personnel. 

B. GLOBAL COMMAND AND CONTROL SYSTEM (GCCS) 

1. Overview 

The Global Command and Control System (GCCS) is an automated system designed to 
support planning and become the single C4I system to support the warfighter. GCCS is the 
midterm solution to a C"^! for the Warrior (C"^fFl W) concept, which is committed to providing a 
joint system providing total battlespace information to the warrior. GCCS is a common operating 
environment (COE) that eliminates the need for stovepipe command and control systems. GCCS 
allows for the migration of existing systems into a COE connected across the SIPRNET and 
allows for the integration of C2 systems into an interoperable system. (After GCCS - Global 
Command and Control System - United States Nuclear Eorces) 

The first priority of GCCS is to become a globally connected, interoperable, fully 
integrated C4 system. Its common operational picture correlates and fuses data from multiple 
sources to provide the information needed to react decisively. GCCS enables joint force 
commanders to synchronize actions of multiple forces and has the flexibility to be used in 
operations from actual combat to humanitarian assistance. (After What is the Joint Command & 
Control System (GCCS-J)) 

2. Components 

GCCS is made up of database servers, applications servers and chents. Connectivity is 
provided through the Defense Information System Network (DISN), and Secret connectivity is 
provided over the SIPRNET. (After What is the Joint Command &Control System (GCCS-J)) 
GCCS infrastmcture includes a client server environment operating on an IEEE LAN, a GCCS 
Executive Subsystem (GES) that allows the user to launch GCCS apphcations, an Information 
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Management Subsystem (IMS), a Reference File Manager, and a communications capability. 
(After GCCS- Global Command and Control System - United States Nuclear System) GCCS 
only works on Hewlett-Packard (HP) workstations. 

C. GLOBAL COMMAND AND CONTROL SYSTEM - MARITIME 

GCCS- Maritime (GCCS-M), previously known as the Joint Maritime Command 
Information System (JMCIS), is the Navy’s primary fielded command and control system. 
GCCS-M affords operational commanders the capability to receive, retrieve, and display 
information in a Common Operating Picture. (After Global Command and Control System - 
Maritime) GCCS-M developed over a number of years of various C4I initiatives, and evolved 
into a system, which allows apphcations to be run on a “superset” of core software. The core 
includes capabilities such as track and relational database management, tactical display, and 
communications interfaces. (After Module 8 - InteUigence Automated Data Processing System) 

D. GCCS-M / MEDAL 

1. Overview 

The Mine Warfare Environmental Decision Aids Library (MEDAL) is one component of 
the GCCS-M. Like GCCS, MEDAL only works on Hewlett Packard workstations. Incorporation 
of the MEDAL into GCCS-M has strengthened the relationship between the MCM commander 
and the Carrier Battle Group (CVBG)/Amphibious Ready Group (ARG). MEDAL has increased 
the MCM Commander’s contribution to the Common Operational Picture, and provides a 
coordinated MIW tactical picture. Using MEDAL, operators can import asset positions, contact 
positions, and environmental information, such as bathymetry, sound speed, and temperature and 
current data, and view the processed picture on screen. 

2. Components 

MEDAL contains several databases, including mine countermeasures, environmental and 
mine threat databases. These databases can be used for mine warfare (MIW) planning 
management, and are common and available to the entire navy. MEDAL allows the user to 
import a chart of an operational area with lanes and Q-routes. Once an area is defined, the user 
can plot planned and actual tracks, as well as asset positions. Contacts can be plotted with 
imbedded information and images. 
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In addition to databases, MEDAL contains area, contact, and asset directories. The area 
directory provides information about Q-routes and areas that have been cleared of mines. The 
contact directory hsts all known contacts. Each is given a contact reference number (CRN) and, 
if judged by an Explosive Ordnance Disposal (EOD) Officer to be a mine, is given a mine 
reference number (MRN). The directory also includes the confidence level of identification, the 
position, and identification (e.g. bottom mine). EinaUy, the asset directory lists available assets, 
their tasking, and historical data points of tracks that have been mn. 

3. Using MEDAL with AUVs 

Data can be entered into MEDAL one of two ways. Eirst, the data can be entered by 
hand, which is an acceptable method for entering one contact, and is point-by-point. However, 
for numerous points, this method is very laborious, and so data can be entered automatically 
through a network connection. Eor example, messages can be sent into MEDAL via file transfer 
protocol (ETP) if they are in the proper United States Message Text Eormat (USMTE). In the 
various incoming logs (ILOGS), USMTE format is checked automatically, and if the message 
passes, it is immediately processed and the system updates, making the information available to 
aU users. 
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Figure 22. 


GCCS/MEDAL displaying Asset and Contact Positions. (From Weekley, 2003) 


One of the problems with AUVs and MEDAL is that most AUVs store data in text files. 
Data stored on the hard drive of the AUV must first be converted into USMTE before it can be 
loaded into MEDAL. Some data collected by REMUS, such as asset and contact positions, and 
bathymetry information, can be exported from the AUV in USMTE format. This capabUity was a 
requirement of the vehicle when the Navy began the REMUS acquisition process. Most AUVs 
acquired by the Navy have this same requirement. The addition of these types of requirements 
equate to an increase in acquisition costs. 

4. Solutions to AUV - MEDAL Incompatibilities 

One way to change text data into USMTE format is to use the AUV Data Server (ADS). 
The ADS can manage the flow of data over a network, either by polling or by an operator. In 
doing so, the server increases the opportunities to manipulate and display data in new ways. One 
of these ways is by displaying the data in USMTE format. (After Weekley, 2003) Below is a 
screen shot of the ADS graphical user interface. 
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Figure 23. The ADS Graphical User Interface (From Weekley, 2003) 

Another solution is to transform the stored text file into an XML document. Once in 
XML, a stylesheet can be used to transform the data into the desired format. At first glance, this 
solution appears to be less desirable than transforming the data directly into USMTF, because of 
the addition of the intermediate transformation into XML. However, the use of an intermediate 
XML document is beneficial for several reasons. First, XML documents must be weU formed 
and vahdated against a schema. Existing software will check documents for stmcture and for 
validation against the governing schema. When a file does not match, the following type of error 
message occurs, and the error is highlighted. 


O This file is not valid: 

Mandatory element 'ClassCode' expected in place of 'Title' 


O This file is not well-formed: 

name closing element name expected. 

Figure 24. XML Spy Not Valid and Not WeU-Formed Errors. 
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On the other hand, M R P AT, offers only pass or fail when checking messages. If the 
message fails, there is no parser to automatically emphasize where the error occurred. In order to 
correct the message, the user must manually parse and correct the document, which can be very 
laborious and time consuming. 

Another advantage of using XML over direct conversion to MEDAL is the abihty to 
modernize the system. MEDAL is essentially mnning on technology that is 20 years old. To 
update the technology, one to five years of preparation, and Congressional permission are 
required, before the acquisition process even starts. A web year is said to be “the length of time it 
takes for the Internet technology to evolve as much as technology in another environment might 
evolve in a calendar year.” (Erom Web Year) A web year is said to be about three months. 
Therefore, by the time MEDAL can be updated, the desired technology is already four to twenty 
years out of date. Also, USMTE files from early versions are no longer useful. Conversely, XME 
upgrades quite frequently. Also, all early version XME documents will vahdate under later 
versions. Therefore, while exporting data in USMTE format offers the luxury of a single 
transformation, exporting to XME offers much greater versatihty, error-correction, and syntactic 
correctness. 
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E. SUMMARY 

While the Navy eurrently requires that AUVs be able to export eertain data in USMTF 
format for uploading into GCCS/MEDAL, this system is not always effective. Occasionally, the 
MRP AT. message is not correctly formatted, and MEDAL wiU not accept the message. Also, 
MEDAL is not easily upgraded, and archiving information is expensive and impractical. XML is 
a viable solution to this problem. By exporting data gathered on a mission in XML format, the 
document can easily be transformed into USMTL format using XSLT, but can also be easily 
transformed into any necessary language, and can also be archived for later use. 
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VIIL FUTURE CONCEPTS 


A. UNDERWATER COMMUNICATIONS 

Land-based digital communications are traditionally accomplished using radio or light- 
based transmissions. However, underwater communications pose a problem. (After Schrope, 
2003) Long distance communications, such as those used for submarine contacts, can be 
accomphshed on a low-frequency carrier, but the system is expensive, and the link is one-way. 
Additionally, these modems offer a data rates around 100 bits per second (bps). An alternative to 
radio and hght wave communications is the acoustic channel. (After Schweber, 2001). The basic 
idea of underwater acoustics is to convert bits of information into tones, which are then 
converted back to digital data at the receiver. Because of the transmission problems introduced 
by underwater transmissions, the bits are sent as multiple tones to ensure the arrival of at least 
some. (After Schrope, 2003) Even as the redundancy in transmissions increases the chance that 
the message will arrive and be interpreted correctly, the redundancy makes the transfer of data 
even slower. 

While the acoustic channel can be used over moderate distances of three to seven 
kilometers, increasing the data rate of the above long range communications by a factor of 24, 
the rate is stiU quite slow compared to land-based communications. In addition, land-based 
communications are almost 186,000 times faster than the speed of sound in water. (After 
Schrope 2003) Most AUVs collect some type of data, such as bathymetry, bottom type, contact 
positions, and asset positions. Ideally, this information can be transmitted to the command ship 
during the mission, without removing the AUV from its task. Though these files may be large, 
they typically contain data in the same format. Although large files, like images and sound, 
cannot be avoided, files containing similar types of data can be compressed using a technique 
called XML seriahzation. 

B. XML SERIALIZATION 

“Serialization is the process of converting an object into a form that can be readily 
transported.” (From Introducing XML Serialization) This process is especially necessary for use 
with XML documents, because even a short XML document can quickly exceed the Maximum 
Transmission Unit (MTU), 1500 bytes for Ethernet. XME Serialization compacts XME 
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documents by replacing elements and attributes with specified tokens. Once serialized, the data 
can be passed, and then deserialized at the receiver. (After Serin, 2003) 

Data compression typically minimizes the amount of data necessary to represent some 
information. Often referred to as coding, the objective of data compression is to represent source 
messages with corresponding code. XML uses markups to identify and describe data. While the 
markup stmcture is not economic, as stated in Chapter fV: terseness is of minimal importance, 
the characteristics of XML are fundamental for compression. Efficient representation of symbols 
leads to a decrease of the space needed to store it, and if the data is self-describing, data can be 
identified based on type and semantics. One system that has been developed for the compression 
of XML data is to use lossless compression techniques for the markup stmcture and both lossless 
and lossy techniques for the data itself. Lossless and lossy techniques refer to the techniques 
reversibihty. Lossless compression means that decoded data are identical to original data; 
otherwise the compression technique is lossy. 

C. FORWARD ERROR CORRECTION (EEC) 

Forward Error Correction (EEC) is a “method of data encoding which gives the receiver 
the abihty to correct data received in error up to a preset bound.” According to thesis work 
performed in 1995, EEC can reduce the number of required retransmissions by 3 to 15 percent. 

The use of EEC is beneficial because acoustic shallow-water data transmissions are unrehable 
and an autonomous entity will often experience problems when passing a message to its intended 
reveicer. EEC is a beneficial solution to this ‘retry until you die’ syndrome, because it is easily 
implemented, the most basic implementation requiring the use of a simple Hamming code. (See 
Reimers, 1995 for more detail) As with the implementation of a XME-based mission control 
language, one goal of EEC is standardization of the underwater acoustic data communications 
community. (After Reimers, 1995) 

D. USING SERIALIZATION TO IMPROVE UNDERWATER COMMUNICATIONS 

Even though the speed of sound is almost five times faster in water than in air, the data 
transfer rate underwater does not compare to the data rate of land-based communications, which 
essentially travel at the speed of hght. (After Schrope, 2003) Therefore, the ability to greatly 
decrease the size of the file to be transferred would be make for an improvement in the speed of 
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underwater communications. By programming the AUVs to export data in XML format, the data 
could be seria liz ed and then transferred at a much better rate. 

E. SEMANTIC WEB AND APPLICATIONS 

The Semantic Web is the “representation of data on the World Wide Web. It is a 
collaborative effort led by [World Wide Web Consortium (W3C)] with participation from a large 
number of researchers and industrial partners.’’(From W3C Semantic Web) Rather than being a 
separate Web, the Semantic Web will be an extension of the existing World Wide Web. Through 
the conceptual Semantic Web, information is given “well-defined meaning, better enabhng 
computers and people to work in cooperation.” (From Scientific American, 2001) One important 
technology needed for the development of the Semantic Web that is already in place is XML. 
XML allows the user to “add arbitrary stmcture to their documents but says nothing about what 
the stmctures mean.” (From Scientific American, 2001) 

The idea of the Semantic Web is to make data on the web available to programs and 
machines, much the way it is available to people. The Semantic Web apphcations can also be 
applied to data coming to and from AUVs. Currently, data from an AUV script file is readable 
by humans. However, machines cannot process those same files. By exporting that data in a 
machine readable, vahdatable format, such as XML, the data can be archived, and reused months 
or years later, by machines or programs, without a human in the loop. In addition, a vahdatable 
file can be checked for completeness and correctness, vice just completeness. 

F. SECURITY APPLICATIONS 

In order to address the security issues created by XML, the W3C has created a 
recommendation for security and authentication technologies called XML Digital 
Signatures.(After Deitel, 2001) “Digital signatures provide integrity, signature assurance, and 
non-repudiatability over Web data.” (From Digital Signature Activity Statement, June 2003) 
These features are especiahy important to documents that contain such information as contracts, 
price hsts, and manifests, and can be applied to use in transmission of data to and from AUVs. 
Much of the data used in conjunchon with the vehicles is sensitive material, and security of this 
information is critical. 

Cryptology, a branch of apphed mathematics concerned with transforming messages in to 
unintehigible forms and back again, is used to create and verify digital signatures. Digital 
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signatures can take the form of a public or secret key system. With a secret key, both the sender 
and receiver must have the key to verify the information. However, with a pubhc key, a sender 
can sign a piece of information and anyone possessing the pubhc key can authenticate that 
information. (From Digital Signature Activity Statement, June 2003) 

As mentioned above, a goal for AUVs is to be able to perform wireless communications 
between an AUV on a mission and a master AUV, or a data coUecting station. In these types of 
situations, security becomes a major issue. Security of AUV missions may become important in 
tactical situations. Security is needed both through the water, and over the Internet when orders 
are transmitted. Acoustic communications are fiindamentahy insecure and low bandwidth. 
However, encryption and authentication, in the form of digital signatures and key distribution, 
are already specified for XML. Thus, an XML based mission command language has a readily 
available, no-cost security capability. As always, any use of security in the underwater 
environment wiU be case dependant and require careful implementation. 

G. SUMMARY 

Many opportunities for future work arise with the use of XML for AUVs. As always, 
underwater communications require compressed files, in order to overcome problems due to low 
bandwidth, and also redundancy and forward error correction to overcome the amount of loss 
and interference experienced during underwater communications. The Semantic Web is the new 
frontier for web apphcations and the use of XML as a mission command language for AUVs 
begins to make the inclusion of AUVs and the data coUected by AUVs on the Semantic Web 
possible. Finahy, the use of acoustic communications creates many security issues that can be 
cheaply and easily addressed using XML. 
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IX. CONCLUSIONS AND RECOMMENDATIONS 


According to Tim Berners-Lee’s keynote address at the WWW 2003 Symposium in 
Budapest, Hungary May 2003, there are three stages to new users adopting XML. The lirst stage 
is what the heck is this stuff, and why is it useful for anything? Next, the user decides he wiU use 
XML, but he doesn’t have to understand or like it. Finally, the user picks up his laptop and tells 
everyone, yeUing, “Look at this! The whole world is here on my laptop!” The purpose of this 
thesis was to bring the reader at least to stage two. Numerous conclusions and recommendations 
for future worth follow 

A. CONCLUSIONS: AUVS AND XML 

Currently, each type of AUV, e.g. REMUS, BPAUV, RMS, and LMRS, has a distinct 
acquisition program and area of operation. While each vehicle performs similar operations, they 
are unable to communicate without a human in the loop. One solution, introduced in this thesis, 
is to create a common mission and data formatting language, using XML. Once AUVs become 
more prevalent in the Navy’s work, commands are lik ely to be using multiple vehicles, for 
multiple depth ranges. Without a common mission and data formatting language, multiple 
vehicles mean multiple operators, or one operator, well versed in several computer-programming 
languages. Not only is XML simple to learn, relative to other computer languages, it also offers 
several other advantages. First, an XML document must be well formed, meaning that is must 
have syntactic correctness. While other languages will not operate properly without proper 
syntax, none offers the immediate highhghting of the syntax error that any parser will give in an 
XML document. Second, XML documents must vahdate against a schema. In the schema, the 
operator can specify ranges for values or can require that the user enter one of a number of 
specified options. Using a tool hke XML Spy, the user can vahdate their mission document 
against the schema, and highhght any mistakes. For example, if the vehicle references depth to 
the water’s surface and operates with depth as a positive number, the schema can be designed to 
only ahow positive values for depth. If a user tries to enter a negative number for depth, the 
schema wiU not vahdate, and the error wih be highhghted. 

Not only must XMF be weh formed, but the tags must also match those specified in the 
schema, both spelhng and case. Once again, an error with the tag will prevent the XMF 
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document from validating. This feature of XML makes the need for redundant commands 
unnecessary. Currendy, the vehicle languages offer several synonyms of each command in the 
hopes of avoiding a misspelled command. The best-case scenario of a misspelled command is 
that the vehicle does not complete the assigned mission. The worst-case scenario of a misspelled 
word is that the vehicle shuts down, sinks and is never seen again. 

B. THE BIGGER PICTURE 

Current AUV acquisition programs require that the vehicle be able to output certain 
information, such as bathymetry, bottom type, and contact and asset position, in USMTF format. 
The stored data can be exported directly from the vehicle’s hard drive, over a network, into 
GCCS-M/MEDAL. In addition, the ADS can take a mission data file, strip out the desired data, 
and convert it into USMTF format. However, neither of these methods allow for quick parsing 
and error correction. When a message is uploaded into MEDAL, it is automatically checked for 
proper format and then given a pass or fail. In order to correct a failed message, it is sometimes 
necessary to delete and recreate huge chun ks of data, which can be time-consuming and tedious. 
Using XML, a message will not validate, unless well formed, and in the format required by the 
schema. A simple XSLT style sheet can then be used to transform the document into USMTF 
format, for uploading into MEDAL. Again, a simple parser immediately finds any errors. 

Another reason that exporting in XML is an improvement over exporting in USMTF and 
directly into the MEDAL system is that XML keeps relative pace with the advancement of 
technology. While XML updates occur frequently, an update to the MEDAL system requires 
Congressional approval, and anywhere from one to five years of red tape. By comparison, a web 
year is approximately three months, so by the time the MEDAL update is approved, the 
technology is already four to 20 years out of date. 

C. RECOMMENDATIONS FOR FUTURE WORKS AND CONCEPTS 

The Semantic Web is an extension of the current web, in which information is “given 
well-defined meaning, better enabhng computers and people to work in cooperation.” (From 
Berners-Lee, Hendler, Lassila) XML is an important technology already in place for the 
Semantic Web, because it allows users to add arbitrary stmcture to their documents without 
saying what the stmctures mean. (After Berners-Lee) In the future, commands will lik ely be 
dealing with fleets of AUVs. With the implementation of XML as a common mission and data 
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formatting language, the Semantic Web may be used as a means of communication between 
AUVs, and a store of data, in addition to the MEDAL system. 

Another potential for XML in the underwater realm is the use of XML Seiiahzation. 
XML Serialization and the recently developed Cross Lormat Schema Protocol (XLSP) make it 
possible to compress a very large file into a much smaller one, via tokenization of element tags 
and attributes. This compression is highly desirable in the operation of AUVs, because of the 
need for wireless underwater communications. The density of water inhibits the travel of radio 
and fight waves, while sound travels quite well. However, the data rates remain poor in 
comparison to land-based communications. The compression of data files would be beneficial to 
the speed of data transfer to and from AUVs. 
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APPENDIX A ABBREVIATIONS 


API 

ARG 

ARIES 

AUVs 

BPAV 

bps 

C^I 

C^IFTW 

CLZ 

COE 

COI 

CRN 

CSS 

CSS2 

CVBG 

DISN 

DTD 

EOD 

EEC 

FTP 

GCCS 

GCCS-M 

GES 

HTML 

ILOGS 

IMS 

JMCIS 

LMRS 

MCM 

MEDAL 

MIW 

MRN 

MTU 

NPS 

RDBMS 

REMUS 

RMS 

SGML 

SME 

UAV 

USMTF 

UUV 


Application Progr ammi n g Interface 

Amphibious Ready Group 

Acoustic Radio Information Exchange Server 

Autonomous Underwater Vehicles 

Battlespace Preparation Autonomous Underwater Vehicle 

bits per second 

Command and Control 

Command & Control, Communications, Computers and Intelligence 

G^I for the Warrior 

Coastal Landing Zone 

Common Operating Environment 

Community of Interest 

Contact Reference Number 

Cascading Style Sheets 

Cascading Style Sheets, level 2 

Carrier Battle Group 

Defense Information System Network 

Document Type Declaration 

Explosive Ordnance Disposal 

Forward Error Correction 

File Transfer Protocol 

Global Command and Control System 

GCCS- Maritime 

GCCS Executive Subsystem 

Hypertext Markup Language 

Incoming Logs 

Information Management Subsystem 
Joint Maritime Command Information System 
Long-Term Mine Reconnaissance System 
Mine Countermeasures 

Mine Warfare Environmental Decision Aids Library 

Mine Warfare 

Mine Reference Number 

Maximum Tran s mission Unit 

Naval Postgraduate School 

Relational Database Management System 

Remote Environment Monitoring Units 

Remote Minehunting System 

Standard Generalized Markup Language 

Subject Matter Expert 

Unmanned Aerial Vehicle 

United States Message Text Format 

Unmanned Undersea Vehicle 
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VRML 

Virtual Reality Modeling Language 

W3C 

World Wide Web Consortium 

WWW 

World Wide Web 

X3D 

Extensible 3D Graphics 

XFSP 

Cross Format Schema Protocol 

Xj3D 

Extensible Java 3D Graphics 

XML 

Extensible Markup Language 

XSL 

Extensible Stylesheet Language 

XSL-FO 

XSL Formatting Objects 

XSLT 

Extensible Stylesheet Language for Transformations 
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APPENDIX B AUV MISSION COMMAND AND TELEMETRY 

LANGUAGE DEEINITIONS: XML SCHEMA 


<?xml version="1.0" encoding="UTF-8" ?> 

- <!-- edited with XMLSPY v5 rel. 2 U (http://www.xmlspy.com) by Baibara Van 
Leuvan (Naval Postgraduate School) - - > 

- <!-- 

This schema describes the AUV mission scripting. Refer to the mission.script.Heip fiie for a 
description of the commands. Simiiar command were consoiidated and the assumptions 
made regarding data vaiidation. 

This schema is modification of a schema created by Daniei Kucik. Darrin L. 
Hawkins and Barbara Van Leuvan wiii use it to aid in their thesis work to create a common 
Mission and data formatting ianguage for Autonomous Underwater Vehicies (AUVs). - - > 

- <xs:schema xmins:xs="http:/ / www.w3.org/ 2001/XMLSchema" 

eiementFormDefauit="qualified" attributeFormDefauit="unqualified"> 

- <xs:annotation> 

<xs: documentation >Start of defining data types^xs: documentation> 
</xs:annotation> 

- <xs:simpieType name="absoluteHeadingType"> 

- <xs:annotation> 

<xs: documentation>Defines valid absolute heading 

values^xs: documentation> 

</xs:annotation> 

- <xs: restriction base="xs:decimal"> 

<xs: mininciusive vaiue="0" /> 

<xs: maxinciusive vaiue="359.9" /> 

</xs: restriction> 

</xs:simpieType> 

- <xs:simpieType name="depthType"> 

- <xs:annotation> 

<xs:documentation>Defines valid commanded depth 

values^xs: documentation> 

</xs:annotation> 

- <xs: restriction base="xs:decimal"> 

<xs: mini nciusive vaiue="0" /> 

<xs: maxi nciusive vaiue="164" /> 

</xs: restriction> 

</xs:simpieType> 

- <xs:simpieType name="depthErrorType"> 

- <xs:annotation> 

<xs:documentation>Defines valid values for indicating depth cell 

errors^xs: documentation> 

</xs:annotation> 

- <xs: restriction base="xs:decimal"> 

<xs: mini nciusive vaiue="-100" /> 

<xs: maxi nciusive vaiue="100" /> 
cjxs: restriction> 

</xs:simpieType> 
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<xs:annotation> 

<xs: docunnentation>Can dive tracker parameters be defined by XYZ 
coordinate attribute group or are the values 
different^xs: documentation> 

</xs:annotation> 

<xs:simpleType name="diveTrackerDepthType"> 

- <xs:annotation> 

<xs: documentation>Defines valid dive tracker depth 

values^xs: documentation> 

</xs:annotation> 

- <xs: restriction base="xs:decimal"> 

<xs: mininclusive value="0" /> 

<xs: maxinclusive value="100" /> 

</xs: restriction> 

</xs:simpleType> 

<xs:sinnpleType nanne="diveTrackerXPositionType"> 

- <xs:annotation> 

<xs:documentation >Defines valid values for dive tracker x- 

position</xs:documentation> 

</xs:annotation> 

- <xs: restriction base="xs:decimal"> 

<xs: mini nclusive value="-5000" /> 

<xs: maxi nclusive value="5000" /> 

</xs: restriction> 

</xs:simpleType> 

<xs: simp leType name ="diveTrackerYPositionType"> 

- <xs:annotation> 

<xs:documentation >Defines valid values for dive tracker y- 

position<xs:documentation> 

</xs:annotation> 

- <xs: restriction base="xs:decimal"> 

<xs: mini nclusive value="-5000" /> 

<xs: maxi nclusive value="5000" /> 

</xs: restriction> 

</xs:simpleType> 

<xs: simpleType name ="fileNameType"> 

- <xs:annotation> 

<xs:documentation >Defines valid file names</xs:documentation> 
</xs:annotation> 

- <xs: restriction base="xs:string"> 

<xs: minLength value="l" /> 

<xs: maxLength value="100" /> 

</xs: restriction> 

</xs:simpleType> 

<xs: simpleType name ="gyroErrorType"> 

- <xs:annotation> 

<xs:documentation>Defines valid values for indicating gyro 
offset/ error</xs: documentation > 

</xs:annotation> 

- <xs: restriction base="xs:decimal"> 
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<xs: mini inclusive value-'- 180" /> 

<xs: maxinclusive value="180" /> 

</xs: restriction> 

</xs:simpleType> 

<xs:simpleType name ="hostNameType"> 

- <xs:annotation> 

<xs: documentation>Defines valid host 

names</xs:documentation> 

</xs:annotation> 

- <xs: restriction base="xs:string"> 

<xs: minLength value-'?" /> 

<xs: maxLength value="100" /> 
cjxs: restriction> 

</xs:simpleType> 

<xs:simpleType name ="lateralTranslationRateType"> 

- <xs:annotation> 

<xs: documentation>Defines valid lateral translation 

rates^xs: documentation> 

</xs:annotation> 

- <xs: restriction base="xs:decimal"> 

<xs: mini nclusive value="-0.82" /> 

<xs: maxi nclusive value="0.82" /> 
cjxs: restriction> 

</xs:simpleType> 

<xs:annotation> 

<xs: documentation>Defines latitude and longitude 

types<xs:documentation> 

</xs:annotation> 

<xs:simpleType name ="latitudeType"> 

- <xs:annotation> 

<xs: documentation>Defines valid latitude values (+/- 

ddm m.m mm mm Xxs: documentation > 

</xs:annotation> 

- <xs: restriction base="xs:decimal"> 

<xs: mini nclusive value="-9000" /> 

<xs: maxi nclusive value="9000" /> 
cjxs: restriction> 

</xs:simpleType> 

<xs:simpleType name ="longitudeType"> 

- <xs:annotation> 

<xs:docu mentation >Defines valid longitude values (+/- 

dddmm.mm mm mXxs: documentation > 

</xs:annotation> 

- <xs: restriction base="xs:decimal"> 

<xs: mini nclusive value-'- 18000" /> 

<xs: maxi nclusive value="18000" /> 
cjxs: restriction> 

</xs:simpleType> 

<xs:simpleType name ="pitchAngleType"> 
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- <xs:annotation> 

<xs: documentation>Defines valid 

angles^xs: documentation> 

</xs:annotation> 

- <xs: restriction base="xs:decimal"> 

<xs: mini nclusive value="-30" /> 

<xs: maxinclusive value="30" /> 

</xs: restriction> 

</xs:sinnpleType> 

<xs: simpleType name ="planeAngleType"> 

- <xs:annotation> 

<xs: documentation>Defines valid angles 
planes^xs: documentation> 

</xs:annotation> 

- <xs: restriction base="xs:decimal"> 

<xs: mini nclusive value="-90" /> 

<xs: maxi nclusive value="90" /> 

</xs: restriction> 

</xs:simpleType> 

<xs: simpleType name ="propSpeedType"> 

- <xs:annotation> 

<xs:docu mentation >Defines valid prop 
values-^xs: documentation> 

</xs:annotation> 

- <xs: restriction base="xs:decimal"> 

<xs: mini nclusive value="-3820" /> 

<xs: maxi nclusive value="3820" /> 

</xs: restriction> 

</xs:simpleType> 

<xs: simpleType name ="rangeType"> 

- <xs:annotation> 

<xs:documentation>Defines valid 

values^xs: documentation> 

</xs:annotation> 

- <xs: restriction base="xs:decimal"> 

<xs: mini nclusive value="0" /> 

<xs: maxi nclusive value-'lOOOO" /> 

</xs: restriction> 

</xs:simpleType> 

<xs: simpleType name ="relativeHeadingType"> 

- <xs:annotation> 

<xs: documentation>Defines valid relative 
values-^xs: documentation> 

</xs:annotation> 

- <xs: restriction base="xs:decimal"> 

<xs: mini nclusive value="-359.9" /> 

<xs: maxi nclusive value="359.9" /> 
cjxs: restriction> 

</xs:simpleType> 


pitch 


for the 


speed 


range 


heading 
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<xs: simpleType name ="relativeXPositionType"> 

- <xs:annotation> 

<xs:documentation>Defines valid values for relative x- 

coordinates^xs: documentation> 

</xs:annotation> 

- <xs: restriction base="xs:decimal"> 

<xs: mininclusive value="-5000" /> 

<xs: maxinclusive value="5000" /> 

</xs: restriction> 

</xs:simpleType> 

<xs: simpleType name ="relativeYPositionType"> 

- <xs:annotation> 

<xs: documentation>Defines valid values for relative y- 

coordinates^xs: documentation> 

</xs:annotation> 

- <xs: restriction base="xs:decimal"> 

<xs: mini nclusive value="-5000" /> 

<xs: maxi nclusive value="5000" /> 

</xs: restriction> 

</xs:simpleType> 

<xs: simpleType name ="rollAngleType"> 

- <xs:annotation> 

<xs:documentation >Defines valid roll angles</xs:documentation> 
</xs:annotation> 

- <xs: restriction base="xs:decimal"> 

<xs: mini nclusive value="-30" /> 

<xs: maxi nclusive value="30" /> 

</xs: restriction> 

</xs:simpleType> 

<xs: simpleType name ="rotationRateType"> 

- <xs:annotation> 

<xs: documentation>Defines valid rates of 

rotation</xs:documentation> 

</xs:annotation> 

- <xs: restriction base="xs:decimal"> 

<xs: mini nclusive value="-40" /> 

<xs: maxi nclusive value="40" /> 
cjxs: restriction> 

</xs:simpleType> 

<xs: simpleType name ="rudderAngleType"> 

- <xs:annotation> 

<xs:docu mentation >Defines valid rudder angle 

values^xs: documentation> 

</xs:annotation> 

- <xs: restriction base="xs:decimal"> 

<xs: mini nclusive value="-90" /> 

<xs: maxi nclusive value="90" /> 

</xs: restriction> 

</xs:simpleType> 
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<xs:simpleType name ="seaStateType"> 

- <xs:annotation> 

<xs: documentation>Defines valid sea state 
values^xs: documentation> 

</xs:annotation> 

- <xs: restriction base="xs:integer"> 

<xs: mininclusive value="0" /> 

<xs: maxinclusive value="9" /> 

</xs: restriction> 

</xs:simpleType> 

<xs:simpleType name="st725BearingType"> 

- <xs:annotation> 

<xs:documentation>Defines valid relative heading values for the 
ST-725 sonar<xs:documentation> 

</xs:annotation> 

- <xs: restriction base="xs:decimal"> 

<xs: mini nclusive value="-90" /> 

<xs: maxi nclusive value="90" /> 

</xs: restriction> 

</xs:simpleType> 

<xs:simpleType name="st725PowerType"> 

- <xs:annotation> 

<xs: documentation>Defines valid power values for the ST-725 

sonar<xs:documentation> 

</xs:annotation> 

- <xs: restriction base="xs:decimal"> 

<xs: mini nclusive value="0" /> 

<xs: maxi nclusive value="50" /> 

</xs: restriction> 

</xs:simpleType> 

<xs:simpleType name="st725RangeType"> 

- <xs:annotation> 

<xs:documentation>Defines valid ST-725 Sonar range 

values-^xs: documentation> 

</xs:annotation> 

- <xs: restriction base="xs:decimal"> 

<xs: mini nclusive value="0" /> 

<xs: maxi nclusive value-TOOOO" /> 

</xs: restriction> 

</xs:simpleType> 

<xs:simpleType name ="stlOOOBearingType"> 

- <xs:annotation> 

<xs:documentation>Defines valid relative heading values for the 
ST-1000 sonar<xs:documentation> 

</xs:annotation> 

- <xs: restriction base="xs:decimal"> 

<xs: mini nclusive value="-90" /> 

<xs: maxi nclusive value="90" /> 

</xs: restriction> 
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</xs:simpleType> 

<xs: simpleType name ="stlOOOSweepWidthType"> 

- <xs:annotation> 

<xs: documentation>Defines valid scan widths for the ST-1000 

sonar<xs:documentation> 

</xs:annotation> 

- <xs: restriction base="xs:decimal"> 

<xs: mininclusive value="-90" /> 

<xs: maxinclusive value="90" /> 

</xs: restriction> 

</xs:simpleType> 

<xs: simpleType name="st725SweepWidthType"> 

- <xs:annotation> 

<xs: documentation>Defines valid scan widths for the ST-725 

sonar<xs:documentation> 

</xs:annotation> 

- <xs: restriction base="xs:decimal"> 

<xs: mini nclusive value="-90" /> 

<xs: maxi nclusive value="90" /> 

</xs: restriction> 

</xs:simpleType> 

<xs: simpleType name ="standoffDistanceType"> 

- <xs:annotation> 

<xs:docu mentation >Defines valid values for stand off 

distances^xs: documentation> 

</xs:annotation> 

- <xs: restriction base="xs:decimal"> 

<xs: mini nclusive value="0" /> 

<xs: maxi nclusive value="100" /> 
cjxs: restriction> 

</xs:simpleType> 

<xs: simpleType name ="timeClockType"> 

- <xs:annotation> 

<xs:documentation>Defines valid AUV clock 

values^xs: documentation> 

</xs:annotation> 

- <xs: restriction base="xs:decimal"> 

<xs: mini nclusive value="0" /> 

<xs: maxi nclusive value-TOOO" /> 

</xs: restriction> 

</xs:simpleType> 

<xs: simpleType name ="timeSecondsType"> 

- <xs:annotation> 

<xs: documentatlon>Defines valid time values in 

seconds^xs: documentation> 

</xs:annotation> 

- <xs: restriction base="xs:decimal"> 

<xs: mini nclusive value="0" /> 

<xs: maxi nclusive value-TOOO" /> 
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</xs: restriction> 

</xs:simpleType> 

- <xs:simpleType name="tubeHeadingType"> 

- <xs:annotation> 

<xs:docunnentation>Defines valid tube heading (orientation) 

values^xs: documentation> 

</xs:annotation> 

- <xs: restriction base="xs:decimal"> 

<xs: mininclusive value="0" /> 

<xs: maxinclusive value="359.9" /> 

</xs: restriction> 

</xs:simpleType> 

- <xs:simpleType name="tubeRangeType"> 

- <xs:annotation> 

<xs:docu mentation >Defines valid tube range 

values-^xs: documentation> 

</xs:annotation> 

- <xs: restriction base="xs:decimal"> 

<xs: mini nclusive value="0" /> 

<xs: maxi nclusive value="20" /> 

</xs: restriction> 

</xs:simpleType> 

- <xs:simpleType name="trueRelativeEnumType"> 

- <xs:annotation> 

<xs:documentation>Defines valid direction indicators 
(true/ relative headingsXxs:documentation> 

</xs:annotation> 

- <xs: restriction base="xs:string"> 

<xs: enumeration value-TRUE" /> 

<xs: enumeration value-true" /> 

<xs: enumeration value-True" /> 

<xs: enumeration value-'RELATI VE" /> 

<xs: enumeration value-'relative" /> 

<xs: enumeration value-'Relative" /> 

</xs: restriction> 

</xs:simpleType> 

- <xs:simpleType name="waterCurrentRateType"> 

- <xs:annotation> 

<xs:documentation >Defines valid values for indicating water 

current</xs: documentation> 

</xs:annotation> 

- <xs: restriction base="xs:decimal"> 

<xs: mini nclusive value="-50" /> 

<xs: maxi nclusive value="50" /> 
cjxs: restriction> 

</xs:simpleType> 


- - > 
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<xs:annotation> 

<xs:docunnentation>Start of defining complex types, which will 
make-up the elements contained in root element 
AUVMission. <xs: documentation> 

</xs:annotation> 

<xs: complexType name ="DepthPositionType"> 

- <xs: attribute name="Zcoordinate" type="depthType"> 

- <xs:annotation> 

<xs:documentation>Z coordinate (depth) of the commanded 

waypoint^xs: documentation> 

</xs:annotation> 

</xs: attribute> 

</xs: complexType> 

<xs: attributeGroup name ="EnterTubeAttributes"> 

- <xs:annotation> 

<xs:documentation >Defines the parameter structure for the 
EnterTube Command</xs: documentation> 

</xs:annotation> 

- <xs: attribute name -'range" type="tubeRangeType"> 

- <xs:annotation> 

<xs: documentation>How far forward to travel to be fully 
inside tube^xs: documentation> 

</xs:annotation> 

</xs: attribute> 

- <xs: attribute name -'bearing" type="tubeHeadingType"> 

- <xs:annotation> 

<xs: docu mentation >Tube orientation in 

degrees^xs: documentation> 

</xs:annotation> 

</xs: attribute> 

</xs: attributeGroup> 

<xs: attributeGroup name ="PlanesAttributes"> 

- <xs:annotation> 

<xs: documentation>Defines the parameter structure for setting 
the plane angles<xs:documentation> 

</xs:annotation> 

- <xs: attribute name -'stern" type="planeAngleType"> 

- <xs:annotation> 

<xs: docu mentation >Stern plane angle^xs: documentation> 
</xs:annotation> 

</xs: attribute> 

- <xs: attribute name="bow" type="planeAngleType"> 

- <xs:annotation> 

<xs:documentation>Bow plane angle^xs: documentation> 
</xs:annotation> 

</xs: attribute> 

- <xs: attribute name -'both" type="planeAngleType" use="optional"> 

- <xs:annotation> 

<xs:documentation>Set both the stern and bow plane 
angles equal to the given angle^xs: documentation> 
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</xs:annotation> 

</xs: attribute> 

</xs: attributeGroup> 

<xs: attributeGroup name ="XYZCoordinates"> 

- <xs:annotation> 

<xs: documentation>Defines the parameter structure for setting 
the AUV's posture (position and 

orientationXxs: documentation> 

</xs:annotation> 

- <xs: attribute name="Xcoordinate" type="relativeXPositionType"> 

- <xs:annotation> 

<xs: documentation >Current X position</xs: documentation> 
</xs:annotation> 

</xs: attribute> 

- <xs: attribute name-'Ycoordinate" type="relativeYPositionType"> 

- <xs:annotation> 

<xs: documentation >Current Y position</xs: documentation> 
</xs:annotation> 

</xs: attribute> 

- <xs: attribute name="Zcoordinate" type="depthType" use="optional"> 

- <xs:annotation> 

<xs: documentation >Current Z position</xs: documentation> 
</xs:annotation> 

</xs: attribute> 

</xs: attributeGroup> 

<xs: attributeGroup name ='Angles"> 

- <xs: attribute name="phi" type="rollAngleType"> 

- <xs:annotation> 

<xs: documentation >Current roll angle^xs: documentation> 
</xs:annotation> 

</xs: attribute> 

- <xs: attribute name="theta" type="pitchAngleType"> 

- <xs:annotation> 

<xs: documentation >Current pitch angle^xs: documentation> 
</xs:annotation> 

</xs:attribute> 

- <xs: attribute name="psi" type="absoluteHeadingType"> 

- <xs:annotation> 

<xs: documentation >Current heading</xs:documentation> 
</xs:annotation> 

</xs: attribute> 

</xs: attributeGroup> 

<xs: complexType name ="Sonar725Type"> 

- <xs:annotation> 

<xs: documentation>Defines the parameter structure used for 
the ST-725 Sonar^xs: documentation> 

</xs:annotation> 

<xs: attribute name -'bearing" type="st725BearingType" /> 

- <xs: attribute name -'range" type="st725RangeType"> 
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- <xs:annotation> 

<xs: documentation>Sonar range^xs: documentation > 
</xs:annotation> 

</xs: attribute> 

- <xs: attribute name -'power" type="st725PowerType"> 

- <xs:annotation> 

<xs: documentation>Sonar powers xs:documentation> 
</xs:annotation> 

</xs: attribute> 

- <xs: attribute name -'direction" type="trueRelativeEnumType"> 

- <xs:annotation> 

<xs:documentation>Direction type for bearing (true or 

relativeXxs: documentation> 

</xs:annotation> 

</xs: attribute> 

</xs: complexType> 

<xs: complexType name ="SonarlOOOType"> 

- <xs:annotation> 

cxs: documentation>Defines the parameter structure used for 
the ST-1000 Sonar^xs: documentation> 

</xs:annotation> 

<xs: attribute name -'bearing" type="stlOOOBearingType" /> 

- <xs: attribute name -'direction" type="trueRelativeEnumType"> 

- <xs:annotation> 

<xs:documentation>Direction type for bearing (true or 

relativeXxs: documentation> 

</xs:annotation> 

</xs: attribute> 

</xs: complexType> 

<xs:annotation> 

<xs: documentation>Define basic structure for all commands used to 
set speed </ xs: documentation> 

</xs:annotation> 

<xs: complexType name ="SpeedType"> 

- <xs:annotation> 

<xs: documentation>Defines the parameter structure for setting 
prop speeds<xs:documentation> 

</xs:annotation> 

- <xs: attribute name="StarboardPropSpeed" type="propSpeedType"> 

- <xs:annotation> 

<xs:documentation>Starboard prop 

speed-^xs: documentation> 

</xs:annotation> 

</xs: attribute> 

- <xs: attribute name="PortPropSpeed" type="propSpeedType"> 

- <xs:annotation> 

<xs: docu mentation >Port prop speed</xs: documentation> 

</xs: annotation> 

</xs: attribute> 

- <xs: attribute name="both" type="propSpeedType" use="optional"> 
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- <xs:annotation> 

<xs:docunnentation>Set both port and starboard props to 
given value^xs: documentation> 

</xs:annotation> 

</xs: attribute> 

</xs: connplexType> 

<xs: attributeGroup name ="StationAttributes"> 

- <xs:annotation> 

<xs: documentation >Defines the parameter structure for the 
stationkeeping commands^xs: documentation> 

</xs:annotation> 

- <xs: attribute name="rangeToTarget" type="rangeType" 

use="required"> 

- <xs:annotation> 

<xs:documentation>Range to sonar 

target^xs: documentation> 

</xs:annotation> 

</xs: attribute> 

- <xs: attribute name -'bearingToTarget" type="absoluteHeadingType" 

use="required"> 

- <xs:annotation> 

<xs: documentation>Bearing to sonar 

target^xs: documentation> 

</xs:annotation> 

</xs: attribute> 

- <xs: attribute name="commandedRange" type="rangeType" 
use="optional"> 

- <xs:annotation> 

<xs: documentation>Commanded range<xs: documentation> 
</xs:annotation> 

</xs: attribute> 

- <xs: attribute name="commandedHeading" 

type="absoluteHeadingType" use="optional"> 

- <xs:annotation> 

<xs: documentation>Commanded 
heading</xs:documentation> 

</xs:annotation> 

</xs: attribute> 

- <xs: attribute name="psi" type="absoluteHeadingType" 

use="optional"> 

- <xs:annotation> 

<xs:documentation>Commanded AUV 

heading</xs:documentation> 

</xs:annotation> 

</xs: attribute> 

</xs: attributeGroup> 

<xs: attributeGroup name ="WaterCurrentAttributes"> 

- <xs:annotation> 

<xs:documentation >Defines the parameter structure used to 
describe water currents<xs:documentation> 
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</xs:annotation> 

<xs: attribute name ="xAxis" type="waterCurrentRateType" 
use="required"> 

- <xs:annotation> 

<xs: documentation>Water current in the north-south 
direction-^ xs: documentation> 

</xs:annotation> 

</xs: attribute> 

<xs: attribute name-'yAxis" type="waterCurrentRateType" 

use="required"> 

- <xs:annotation> 

<xs: docu mentation >Water current in the east-west 
direction-^ xs: documentation> 

</xs:annotation> 

</xs: attribute> 

<xs: attribute name="zAxis" type="waterCurrentRateType" 

use="optional"> 

- <xs:annotation> 

<xs:documentation>Water current in the up-down 

direction^xs: documentation> 

</xs:annotation> 

</xs: attribute> 
xs:attributeGroup> 


- <xs: element name- AUVMission"> 

- <xs:annotation> 

<xs:documentation>AUV Mission Script^xs: documentation> 
</xs:annotation> 

- <xs:complexType> 

- <xs: sequence maxOccurs="unbounded"> 

<xs: element name -'Profile" /> 

- <xs: element name="l nsertPoint"> 

- <xs:annotation> 

<xs: documentation>Where the vehicle enters the 
water. <xs:documentation> 

</xs:annotation> 

- <xs:complexType> 

<xs: attributeGroup ref="XYZCoordinates" /> 

</xs: complexType> 

</xs:element> 

- <xs: element name -’Waypoints" minOccurs="0"> 

- <xs:annotation> 

<xs: documentation>Drive to the given 
waypoint^xs: documentation> 

</xs:annotation> 

- <xs:complexType> 

- <xs: attribute name -'number" type="xs:integer"> 
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- <xs:annotation> 

<xs: docunnentation>l D number of the 
commanded 

waypoint^xs: documentation> 

</xs:annotation> 

</xs: attribute> 

<xs: attributeGroup ref="XYZCoordinates" /> 

</xs: complexType> 

</xs:element> 

<xs: element name - 'StarboardPropSpeed" 

type="propSpeedType"> 

- <xs:annotation> 

<xs:documentation>Starboard prop 

speed </xs: documentation> 

</xs:annotation> 

</xs:element> 

<xs: element name -'PortPropSpeed" 

type="propSpeedType"> 

- <xs:annotation> 

<xs: docu mentation >Port prop 

speed-^xs: documentation> 

</xs:annotation> 

</xs:element> 

<xs: element name -Thrusters" type="xs:boolean" 
min0ccurs="0"> 

- <xs:annotation> 

<xs: documentation>Enable vertical and lateral 
thruster controKxs:documentation> 

</xs:annotation> 

</xs:element> 

<xs: element name -'Rudder" type="rudderAngleType" 

min0ccurs="0"> 

- <xs:annotation> 

<xs: documentation>Set the rudder angle (thrusters 
off) </xs: documentation> 

</xs:annotation> 

</xs:element> 

<xs: element name-'ChangeCourse" 

type="relativeHeadingType" min0ccurs="0"> 

- <xs:annotation> 

<xs: docu mentation >Adjust heading by the given 
number of degrees (positive for starboard and 
negative for port)</xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs: element name-'PlanesAngle" min0ccurs="0"> 

- <xs:annotation> 

<xs: docu mentation >Set the angle of the planes 
(thrusters off) </xs: docu mentation > 

</xs:annotation> 
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- <xs:complexType> 

<xs: attributeGroup ref="PlanesAttributes" /> 

</xs: complexType> 

</xs: element > 

<xs: element name ="CommandedAltitude" 

type="DepthPositionType" min0ccurs="0"> 

- <xs:annotation> 

<xs: documentation>Set a new ordered 

altitude.^xs: documentation> 

</xs:annotation> 

</xs:element> 

<xs: element name ="CommandedDepth" 

type="DepthPositionType" min0ccurs="0"> 

- <xs:annotation> 

<xs: documentation>Set a new ordered 

depth. <xs: docu mentation > 

</xs:annotation> 

</xs:element> 

<xs: element name="PitchAngle" type="pitchAngleType" 
min0ccurs="0"> 

- <xs:annotation> 

<xs: documentation>Set a new ordered pitch 
angle. <xs: documentation> 

</xs:annotation> 

</xs:element> 

<xs: element name -Theta" type="pitchAngleType" 
min0ccurs="0"> 

- <xs:annotation> 

<xs: documentation>Set a new ordered pitch 
angle. <xs: documentation> 

</xs:annotation> 

</xs: element> 

<xs: element name -'Rotate" type-'rotationRateType" 

min0ccurs="0"> 

- <xs:annotation> 

<xs: documentation>Open loop lateral thruster 
rotation control at the given rate 
(degrees/ sec).<xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs: element name -'Lateral" 

type="lateralTranslationRateType" min0ccurs="0"> 

- <xs:annotation> 

<xs: documentation>Open loop lateral thruster 
translation control in given ft/sec. (positive is 
to starboard, max is -0.82 ft/ sec) Thruster 
orders are constrained to +/ - 24.0 volts = 3820 
rpm no-load interestingly some yaw occurs in 
open-loop control. <xs: documentation> 

</xs:annotation> 
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</xs:element> 

<xs:element name-'DiveTracker" min0ccurs="0"> 

- <xs:annotation> 

<xs:docunnentation>Position of DiveTracker 
transducer l.</xs:docunnentation> 

</xs:annotation> 

- <xs:complexType> 

<xs: attributeGroup ref="XYZCoordinates" /> 

</xs: connplexType> 

</xs: element > 

<xs: element name ="AltitudeOrDepthControl" 

type="xs:boolean" min0ccurs="0"> 

- <xs:annotation> 

<xs: documentation >1 ndicated whether Altitude or 
Depth Control is on or off<xs: documentation> 
</xs:annotation> 

</xs:element> 

<xs: element name="PerformGPSPopup" type="xs:boolean" 

minOccurs="0"> 

- <xs:annotation> 

<xs: documentation>GPS fix complete, resume 
previously ordered depth. <xs:documentation> 
</xs:annotation> 

</xs:element> 

<xs: element name - 'DurationGPSPopup" 

type="timeSecondsType" minOccurs="0"> 

- <xs:annotation> 

<xs:documentation>Duration, in seconds, to 
proceed to shallow depth, take GPS fix, restore 
ordered depth when done.<xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs: element name="GyroError" type="gyroErrorType" 
minOccurs="0"> 

- <xs:annotation> 

<xs: documentation>Degrees of error measured for 
gyro-compassGYRO + ERROR = 

TRUE^xs: documentation> 

</xs:annotation> 

</xs:element> 

<xs: element name="DepthCellError" type="depthErrorType" 

minOccurs="0"> 

- <xs:annotation> 

<xs:documentation>Feet of bias error measured for 
depth cell.DEPTH CELL Z + BIAS = TRUE 

Z<xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element name -'Position" minOccurs="0"> 

- <xs:annotation> 
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<xs: documentation>Reset vehicle's dead reckoning 
position. <xs: docu mentation > 

</xs:annotation> 

- <xs:complexType> 

<xs: attributeGroup ref="XYZCoordinates" /> 

</xs: complexType> 

</xs:element> 

<xs:element name -'Orientation" minOccurs="0"> 

- <xs:annotation> 

<xs:documentation>Reset vehicle's 

orientation-^ xs: documentation> 

</xs:annotation> 

- <xs:complexType> 

<xs: attributeGroup ref="Angles" /> 

</xs: complexType> 

</xs:element> 

<xs: element name -'Posture" minOccurs="0"> 

- <xs:annotation> 

<xs: docu mentation >Reset vehicle's posture 

(position and orientationXxs: documentation> 
</xs:annotation> 

- <xs:complexType> 

<xs: attributeGroup ref="XYZCoordinates" /> 

<xs: attributeGroup ref-'Angles" /> 

</xs: complexType> 

</xs:element> 

<xs: element name-'OceanCurrent" minOccurs="0"> 

- <xs:annotation> 

<xs: documentation>Ocean current 

rate-^xs: documentation> 

</xs:annotation> 

- <xs:complexType> 

<xs: attributeGroup ref-'WaterCurrentAttributes" /> 

</xs: complexType> 

</xs:element> 

<xs: element name="SeaState" type="seaStateType" 
minOccurs="0"> 

- <xs:annotation> 

<xs: documentation>Estimate of surface sea state 
[0-9]<xs: documentation> 

</xs:annotation> 

</xs:element> 

<xs: element name-'WatchRadius" type="rangeType" 
minOccurs="0"> 

- <xs:annotation> 

<xs: documentation>Circular area that if the ARIES 
gets inside that distance it has achieved it's 
goal of navigating to the 

waypoint^xs: documentation> 

</xs:annotation> 
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</xs:element> 

<xs: element name ="WaypointTimeout" 

type="timeSecondsType" min0ccurs="0"> 

- <xs:annotation> 

<xs: documentation>Time in seconds until the 
ARIES will discontinue navigating toward that 
waypoint. </ xs: documentation> 

</xs:annotation> 

</xs:element> 

<xs: element name ="StandOff Distance" 

type="standoffDistanceType" minOccurs="0"> 

- <xs:annotation> 

<xs:documentation>Change standoff distance for 
WAYPOl NT and HOVER 

controKxs: documentation> 

</xs:annotation> 

</xs:element> 

<xs:element name -'Hover" minOccurs="0"> 

- <xs:annotation> 

<xs: documentation>Hover at present (or provided) 
position and depth<xs:documentation> 
</xs:annotation> 

- <xs:complexType> 

- <xs:annotation> 

<xs:docu mentation >Defines the parameter 
structure for the hovering 

com mands< xs: documentation > 

</xs:annotation> 

- <xs:attribute name -’enabled" type="xs:boolean"> 

- <xs:annotation> 

<xs: documentation>Hover mode is on or 
off</xs: documentation> 

</xs:annotation> 

</xs: attribute> 

<xs:attributeGroup ref="XYZCoordinates" /> 

</xs: complexType> 

</xs:element> 

<xs:element name-'TargetStation" minOccurs="0"> 

- <xs:annotation> 

<xs: documentation>Hover relative to sonar target 
at the given range and bearing with AUV 
pointing at the target. Stationkeeping will use 
full target tracking sonar 

mode.^xs: documentation> 

</xs:annotation> 

- <xs: complexType> 

<xs:attributeGroup ref="StationAttributes" /> 

</xs: complexType> 

</xs:element> 
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<xs: element name-TargetPoint" type="xs:boolean" 
minOccurs="0"> 

- <xs:annotation> 

<xs:documentation>Commanded Psi during 
stationkeeping will point directly at target 
center-^ xs: documentation> 

</xs:annotation> 

</xs:element> 

<xs:element name="EnterTube" minOccurs="0"> 

- <xs:annotation> 

<xs: documentation>Experimental control mode. 

This tells execution level that nose has entered 
the tube, drive the rest of the way in using 
dead reckon for forward motion and sonars 
(pointing to opposite sides) to maintain tube 
side wall standoff. <xs: documentation> 

</xs:annotation> 

- <xs:complexType> 

<xs: attributeGroup ref="EnterTubeAttributes" /> 

</xs: complexType> 

</xs:element> 

<xs: element name -’Wait" type="timeSecondsType" 
minOccurs="0"> 

- <xs:annotation> 

<xs: documentation>Wait for #a seconds prior to 
reading from the script file 

again^xs: docu mentation > 

</xs:annotation> 

</xs:element> 

<xs: element name="WaitUntil" type="timeClockType" 
minOccurs="0"> 

- <xs:annotation> 

<xs: documentation >Wait (or run) until robot clock 
reaches time #a (letting the AUV execute its 
current orders) prior to reading from the script 
file again. If #a is earlier than current time, 
reset the clock. If in TACTICAL mode, command 
is ignored. <xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs: element name-TimeStep" type="timeSecondsType" 
minOccurs="0"> 

- <xs:annotation> 

<xs: documentation>Change default execution level 
time step interval from default of 0.1 sec to the 
provided number of 

seconds^xs: documentation> 

</xs:annotation> 

</xs:element> 

<xs: element name="SingleStep" type="xs:boolean" 
minOccurs="0"> 
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- <xs:annotation> 

<xs: docunnentation>Loop for another timestep prior 
to reading script again. Only useful in execution 
keyboard mode.<xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs: element name -'Pause" type="xs:boolean" 

min0ccurs="0"> 

- <xs:annotation> 

<xs: documentation>Stop execution until (enter) is 
pressed </xs:documentation> 

</xs: annotation> 

</xs:element> 

<xs: element name="RealTime" type="xs:boolean" 
min0ccurs="0"> 

- <xs:annotation> 

<xs:documentation>Run execution level code in 
real-time( busy wait at the end of each timestep 
if time remainsXxs: documentation> 

</xs:annotation> 

</xs:element> 

<xs: element name -’Virtual" type="hostNameType" 
min0ccurs="0"> 

- <xs:annotation> 

<xs:documentation>Tells the execution level to 
open a socket to the virtual world which is 
already running and waiting on #a. 

VIRTUALHOST is a command line 
switch. <xs: documentation> 

</xs:annotation> 

</xs:element> 

<xs: element name-'LocationLab" type="xs:boolean" 
min0ccurs="0"> 

- <xs:annotation> 

<xs: documentation>Vehicle is operating in lab 
using virtual world. This is the default 

mode.^xs: documentation> 

</xs:annotation> 

</xs:element> 

<xs: element name -’Tethered" type-’xsiboolean" 
min0ccurs="0’'> 

- <xs:annotation> 

<xs:documentation>Command line switch only, 
used for in-water runs<xs:documentation> 
</xs:annotation> 

</xs:element> 

<xs: element name-'VirtualHost" type-’hostNameType" 
min0ccurs-'0’'> 

- <xs:annotation> 
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<xs:documentation>Tells the execution level to 
open a socket to the virtual world which is 
already running and waiting on #a. 

VIRTUALHOST is a command line 
switch. <xs: documentation> 

</xs:annotation> 

</xs: ele merit > 

<xs: element name -'Mission" type="fileNameType" 

minOccurs="0"> 

- <xs:annotation> 

<xs:documentation>Replace temporary file 
"mission.script" with the given and start the 
new mission. Reads tactical commands for 
execution level from the given 

file.^xs: documentation> 

</xs:annotation> 

</xs:element> 

<xs: element name -’Telemetry" type="fileNameType" 

minOccurs="0"> 

- <xs:annotation> 

<xs: documentation>Playback prerecorded 

telemetry data from the given file. Consider 
using with NOSCRI PT if no script file is 

present^xs: documentation> 

</xs:annotation> 

</xs:element> 

<xs: element name="NoScript" type="xs:boolean" 

minOccurs="0"> 

- <xs:annotation> 

<xs:documentation>lgnore script command file. 
Selectively used in combination with 
TELEMETRY data file 

playback.<xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs: element name -'Keyboard" type="xs:boolean" 

minOccurs="0"> 

- <xs:annotation> 

<xs:documentation>Read script commands from 
keyboard^xs: documentation> 

</xs:annotation> 

</xs:element> 

<xs: element name -'Trace" type="xs:boolean" 

minOccurs="0"> 

- <xs:annotation> 

<xs: documentation>Enable verbose print 
statements in execution 

leveKxs: documentation> 

</xs:annotation> 

</xs:element> 
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<xs: element name-'LoopForever" type="xs:boolean" 
minOccurs="0"> 

- <xs:annotation> 

<xs: docu mentation >Repeat current mission 
indefinitely. Each repetition is called a 
"replication". Do not generate plots after each 
replication^xs: documentation> 

</xs:annotation> 

</xs:element> 

<xs: element name ="ControlConstantsFilename" 

type="fileNameType" minOccurs="0"> 

- <xs:annotation> 

<xs:documentation>Read revised control 

coefficients from the given 

file.^xs: documentation> 

</xs:annotation> 

</xs:element> 

<xs:element name="Text" type="xs:boolean" minOccurs="0"> 

- <xs:annotation> 

<xs: documentation>Turn text display in command 
window on or off<xs: docu mentation > 

</xs:annotation> 

</xs:element> 

<xs:element name="Exit" type="xs:boolean" minOccurs="0"> 

- <xs:annotation> 

<xs: documentation>Do not execute any more 
commands in this script, but repeat the mission 
again if LOOP-FOREVER is 

set.</xs: documentation> 

</xs:annotation> 

</xs:element> 

<xs:element name="SonarCommands" minOccurs="0"> 

- <xs:complexType> 

- <xs: choice> 

- <xs: element name="Sonar725l nstalled" 
type="Sonar725Type" minOccurs="0"> 

- <xs:annotation> 

<xs:documentation>Use the installed 
sonar<xs:documentation> 

</xs:annotation> 

</xs:element> 

- <xs:element name -'SonarlOOOl nstalled" 
type="SonarlOOOType" minOccurs="0"> 

- <xs:annotation> 

<xs:documentation>Use the installed 
sonar<xs:documentation> 

</xs: annotation> 

</xs:element> 

</xs:choice> 

</xs: complexType> 
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</xs:element> 

- <xs: element name -’Sound" type="xs:boolean" 

min0ccurs="0"> 

- <xs:annotation> 

<xs:documentation>Enable text-to-speech audio 
output, on or off<xs: documentation> 

</xs:annotation> 

</xs:element> 

- <xs: element name="EMail" type="xs:boolean" 

minOccurs="0"> 

- <xs:annotation> 

<xs: documentation>Ask user for e-mail address at 
start of mission. E-mail report once mission is 
complete. <xs:documentation> 

</xs:annotation> 

</xs:element> 

- <cxs: element name="SlidingModeCourse" type="xs:boolean" 

min0ccurs="0"> 

- <cxs:annotation> 

<cxs:documentation>Sliding mode course control 
algorithm <xs: documentation> 

</xs:annotation> 

</xs:element> 

- <cxs: element name="ParallelPortTrace" type="xs:boolean" 

min0ccurs="0"> 

- <cxs:annotation> 

<xs:documentation>Enable trace statements for 
parallel port 

communications </xs: docu mentation > 

</xs:annotation> 

</xs:element> 

- <cxs: element name="ExtractPoint"> 

- <cxs:annotation> 

<xs: documentation>Where the vehicle is taken out 
of the water. <xs: documentation> 

</xs:annotation> 

- <cxs:complexType> 

<cxs:attributeGroup ref="XYZCoordinates" /> 

</xs: complexType> 

</xs:element> 

</xs:sequence> 

</xs: complexType> 

</xs:element> 

</xs: schema > 
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APPENDIX D SOFTWARE AVAILABILITY 


1. INTRODUCTION 

This appendix describes the availability and installation for most of the software 
packages used to generate this thesis. This section provides instmctions for downloading and 
installing the software. To create the Common Mission and Data Formatting Language schema, 
one may use XMLSpy. The NFS AUV Workbench is discussed in this thesis and an example 
mission script file in taken from the NFS AUV Workbench to show interoperabUity with existing 
software. Thus, the installation of the NFS AUV Workbench is included. 

2. XMLBASED COMMON MISSION AND DATA FORMATTING LANGUAGE 

To view the XML-based Common Mission and Data Formatting Language, one must 

have a XML editor. This section describes the software availabUity and an overview of the 
installation instmctions. The common XML editor of choice is XMLSpy because it’s the 
industry standard XML Development Environment for building software applications based on 
XML technologies. XMLSpy (version 5) is available at http://www.altova.com/download . 

Download the executable file and follow the installation instmctions. 

3. NFS AUV WORKBENCH 

The NFS AUV Workbench s designed to provide a virtual environment for planning for 
and analyzing AUV operations. The idea is to provide mission scripts, obstacle fields, sonar 
algorithms and an ocean environment and use the Xj3D Browser together with X3D internet 
graphics for representing the virtual environment. (Note: This is the initial version of the AUV 
Workbench. It isn't well documented or fuUy functionally, use at your own risk!) 

The best way to install the software is to use the Install Anywhere package available 
through the Naval Fostgraduate School. This will automatically create a .exe and load the AFIs 
necessary to mn the scenarios. If you only have the .zip file do the following: 

Unzip the AUVWorkbench.zip into a C:/AUVWorkbench directory. 
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Make sure that you have J2SDK1.4.1 loaded and working 
Install the JDOM API, check examples to make sure it is working. 

At a command window change the directory to C:/AUVWorkbench and type AMVW_1.0. 
(This should start the AUVWorkbench GUI program. 

In the XjSDBrowser chck on the open button and open the file AUVMissionScenario.wri. 
This gives a predesigned AUV Mission. 

A note on the architecture. You can create any type on mission profile and obstacles on the 
workbench. Missions are created by importing the various component XML files into a 
master scenario that file is then converted into a X3D file for rendering in the Xj3D browser. 
In other words, go to the Route Planner, open or create an XML mission script and press the 
import button to bring the file into the master scenario. Do the same for the obstacle field. 
Once you have selected and imported the component XML files, open the X3D file via the 
top Xj3D Browser and choose the file GeneralAUVMissionScenario.wri. This will be the file 
that mns the specific mission. 

Send comments questions to dphomer@nps.navy.mil 
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APPENDIX E - MISSION SCRIPT HELP FILE 


H- . H 

mission.script.HELP 10 January 2002 

Mission script syntax for NPS AUV execution ievei and tacticai 
control, in water and in the NPS AUV Underwater Virtual World. 
http://web.nps.navy.mil/~brutzman/auv/execution/mission.script.HELP 
Don Brutzman brutzman@nps.navy.mil 

H- . H 

This file describes how to change and create NPS AUV mission script files. 

Example mission.script files and the 'execution' program are in the 
-/execution subdirectory. 

Script commands are received by the AUV execution level (execution.c) from 
the tactical level during a mission, the operator at the keyboard, or 
read from the "mission.script" file. Both tactical and execution can 
carry out mission scripts. 

To run a new mission, copy a different existing mission file over file 

'mission.script' or edit the mission.script file for a new mission. 

Example: 
unix> cd execution 

unix>cp mission.script.siggraph mission.script 
unix> execution virtual cadet.cs.nps.navy.mil 
or, more simply, 

unix> execution virtual cadet mission mission.script.siggraph 
Many of the following commands will also work when invoked from the command 
line upon execution. Detailed command line guidance is also available 
interactively using the online NPS AUV process launcher form at 
http://blackand.stl.nps.navy.mil/~auv/launcher/launcher.cgi 
Numerous script keywords (and synonyms) are currently recognized. We have been 
generous in the use of synonyms in order to reduce the possibility of 
catastrophic spelling errors. This approach might be further extended 
to include synonyms in other languages (French, Portuguese etc.) 

Hint hint! 

Sections in this syntax help file: 

- Helm commands: open-loop and closed-loop control 

- Navigation commands 

- Mission timing commands 

- Mission setup and configuration commands 

- Sonar commands 

- Miscellaneous commands 
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.+■ 

Keywords | Parameters | Description 

Synonyms | [optional] | (all units are feet, degrees or seconds as appropriate) 

.+.+. 

I I 

// Helm commands: open-loop and closed-loop control.// 

RPM # [##] Set ordered rpm values to # for both propellers 

SPEED # [##] [ or Independently set left & right rpm values 

PROPS # [##] to # and ## respeotively] 

PROPELLORS # [##] maximum propellor speed is -I-- 700 rpm => 2 ft/seo 

/* constrain thruster orders +!- 24.0 volts == 3820 rpm no-load */ 
THRUSTERS-ON Enable vertical and lateral thruster control 

THRUSTERS Thruster orders are oonstrained to 

THRUSTERON +!- 24.0 volts == 3820 rpm no-load 

Default turn-on voltage 0.0 

THRUSTERSON 

NOTHRUSTER Disable vertical and lateral thruster control 

NOTHRUSTERS 

THRUSTERS-OFF 

THRUSTERSOFF 

RUDDER # Force rudder to remain at # degrees, thrusters-off. 

Value Is for after rudder, negative command turns left. 

DEADSTICKRUDDER [#] Force rudder to remain at 0 [or #] degrees, 

thrusters-off. 

COURSE # Set new ordered course (commanded yaw angle) 

HEADING # 

YAW # 

TURN # Change ordered course by # degrees 

CHANGE-COURSE # (positive # to starboard, negative # to port) 

PLANES # [#] Force planes to remain at # degrees, thrusters-off. 

PLANE # [#] Value is for stern planes, negative command points down. 
DEADSTICKPLANES # [#] Note that negative stern planes results in reduction in 
z (i.e. more shallow). If two values are applied, order is PLANES stern bow. 
Thus, for example: 
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PLANES -10 is equivalent to 

PLANES-10 10 #stern=-10, bow=10, go shallow 

DEADSTICKPLANES [#] Force planes to remain at 0 [or #] degrees, 

thrusters-off. 

DEPTH # Set new ordered depth (commanded z) 

PITCH # Set new ordered pitch (commanded theta angle). 

THETA # Only effective during HOVERCONTROL. 

ROTATE # open loop lateral thruster rotation control 

at # degrees/sec 

NOROTATE disable open loop lateral thruster rotation control 

ROTATEOFF 

ROTATE-OFF 

LATERAL # open loop lateral thruster translation control 

in # ft/sec. 

(positive is to starboard, max is -0.82 ft/sec) 
Thruster orders are constrained to 
+!- 24.0 volts == 3820 rpm no-load 
interestingly some yaw occurs In open-loop control. 

NOLATERAL disable open loop lateral thruster translation control 

LATERALOFF 

LATERAL-OFF 


VERTICAL needed I 

H- . H 

H Navigation commands.// 


DIVETRACKER1 ###### Position of DiveTracker transducer 1 
DIVETRACKER2 # ##### Position of DiveTracker transducer 2 

Still need to Incorporate bearing to DIveTrackers. 

GPS Proceed to shallow depth, take Global Positioning 

GPSFIX System (GPS) fix, restore ordered depth when done. 
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GPS-FIX Control (thrusters, propellers/planes, combined) 

is not modified. Maximum fix time is 30 seconds, 
at which time execution returns to previously 
ordered depth. 

GPS-COMPLETE GPS fix complete, resume previously ordered depth. 

GPS-FIX-COMPLETE 

GYRO-ERROR # Degrees of error measured for gyrocompass. 

GYROERROR # [GYRO -r ERROR = TRUE] 

DEPTH-CELL-BIAS # Feet of bias error measured for depth cell. 

DEPTHCELLBIAS # [DEPTH CELL Z-i-BIAS = TRUE Z] 

DEPTH-CELL-ERROR# 

DEPTHCELLERROR # 

POSITION # ## [###] reset vehicle dead reckon position to (x, y) or 

LOCATION ###[###] (x, y, z) = (#,##,###) at current clock time 

FIX ###[###] This is a navigational position fix. Receipt of a 

POSITION/LOCATION/FIX command resets the execution 
level dead-reckon position. Note that depth value z 
will likely be reset by depth cell if operational. 

During virtual world operation, hydrodynamics model 
is rezeroed. 

ORIENTATION ###### reset vehicle orientation to 

ROTATION # ## ### (phi, theta, psi) = (#, ##, ###) 

During virtual world operation, hydrodynamics model 
is rezeroed. 

POSTURE #a #b #c #d #e #f 

reset vehicle dead reckon posture to 

(x, y, z, phi, theta, psi) = (#a, #b, #c, #d, #e, #f) 

OCEANCURRENT #x #y [#z] Ocean current rate along North-axis, East-axis and 

OCEAN-CURRENT #x #y [#z] [optional] Depth-axis (feet/sec) 

(this is cartesian version of parametric set and drift) 
During virtual world operation, hydrodynamics model 
is rezeroed. 


88 



SEASTATE # Estimate of surface sea state, rounds to integer [0..9] 

SEA-STATE # This vaiue is aiso passed to dynamics ievel. 

WAYPOINT #X#Y[#Z] [#rpm] 

WAYPOINT-ON #X #Y [#Z] [#rpm] 

Point towards waypoint with coordinates (#X, #Y) 

(depth #Z optionai) (speed #rpm optional). You can 
leave waypoint control by ordering course, rudder, 
sliding-mode, rotate or lateral thruster control. 

If speed is < 200 RPM, port & starboard RPMs are 
increased to 400 RPM to ensure waypoint can be 
achieved. 

If in TACTICAL mode, execution reports STABLE when 
waypoint is achieved. 

STANDOFF # Change standoff distance for WAYPOINT and HOVER 

STAND-OFF # control. Default value is 2.5 feet for NPS AUV, 

STANDOFFDISTANCE # 50.0 feet for SSN. Default values are automatically 

STANDOFF-DISTANCE # read from control.constants.input.hulltype files. 

STAND-OFF-DISTANCE # 

HOVER Hover at present position and ordered depth using 

thrusters and propellers. 

HOVER without parameters is the preferred method of 
slowing since backing down with negative propellers may 
result in large sternway and severe depth excursions. 

HOVER [#X #Y] [#Z] Hover using thrusters and propellers for lateral and 
longitudinal positioning at specified position. 

Default Z value is previously ordered DEPTH. 

HOVER [#X#Y][#Z] [#orientation] [#standoff-distance] 

Uses WAYPOINT control until within #standoff-distance 
of HOVER point (#X, #Y, #Z), then switches to 
HOVER control with [optional] final #orientation 
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Full speed (700 RPM) port & starboard is used if 
AUV distance to WAYPOINT is > #standoff-distance + 10', 
then slows to 200 RPM until within #standoff-distance, 
then HOVER control. 

If in TACTICAL mode, execution reports STABLE when done. 

HOVEROFF Turn off HOVER mode 

HOVER-OFF 

HOVER_OFF 

TARGETSTATION #R #B [#Psi] 

TARGET-STATION #R #B [#Psi] 

Hover relative to a sonar target at range = #R and 
target bearing #B from the AUV. Commanded AUV 
heading is #Psi (default is point at target). 

Stationkeeping will use full target tracking 
sonar mode 

TARGETSTATION #R1 #B1 #R2 #B2 [#Psi] 

TARGET-STATION #R1 #B1 #R2 #B2[#Psi] 

Hover relative to sonar target. Target currently 
at range = #R1, bearing #B1 from AUV. Commanded 
range = #R2, commanded bearing = #B2, commanded 
heading = #Psi (default is point at target). 

Stationkeeping will use full target tracking 
sonar mode 

EDGESTATION #R #B [#Psi] 

EDGE-STATION #R #B [#Psi] 

Hover relative to a sonar target at range = #R and 
target bearing #B from the AUV. Commanded AUV 
heading is #Psi (default is point at target). 

Stationkeeping will use full target tracking 
sonar mode 

EDGESTATION #R1 #B1 #R2 #B2 [#Psi] 

EDGE-STATION #R1 #B1 #R2 #B2 [#Psi] 

Hover relative to sonar target. Target currently 
at range = #R1, bearing #B1 from AUV. Commanded 
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range = #R2, commanded bearing = #B2, commanded 
heading = #Psi (defauit is point at target). 

Statienkeeping wiii use target edge tracking 
sonar mode 

TARGET-OFF Turn off stationkeeping controi mode 

TARGETOFF 

NO-TARGET 

NOTARGET 

TARGET-POINT Commanded #Psi during stationkeeping wiii point 

TARGETPOiNT directiy at target center 

NO-TARGET-POINT Commanded #Psi during stationkeeping can be 

NOTARGETPOINT manuaiiy contreiied using HEADING commands 

TARGET-POINT-OFF 
TARGETPOINTOFF 

ENTERTUBE ### Experimental control mode. This tells execution level 
ENTER-TUBE # ## that nese has entered the tube, drive the rest of the 

way in using dead reckon for forward motion and sonars 
(pointing to opposite sides) te maintain tube side wall 
standeff. Parameters: 

# How far forward to travel to be fully inside tube 
## Tube erientation in degrees 


// Mission timing commands.// 

WAIT # Wait (or run) for # seconds (letting the robot execute) 

RUN # prior to reading from the script file again 

If in TACTICAL mode, execution ignores WAIT commands. 

NEXTORDERTIME # Wait (or run) until robot clock reaches time # 

WAITUNTIL # (letting the robot execute its current orders) 

PAUSEUNTIL # prior to reading from the script file again 

TIME # 

** If value is earlier than current time, reset the clock. 
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If in TACTICAL mode, execution ignores these commands. 


TiMESTEP # change defauit execution ievei time step intervai 

TIME-STEP # from default of 0.1 sec to # sec 

STEP 

SINGLE-STEP 

PAUSE 

REALTIME 
REAL-TIME 

NOREALTIME 
NO-REALTIME 
NONREALTIME 
NOWAIT 
NO-WAIT 
NOPAUSE 
NO-PAUSE 


H- . H 

H Mission setup and configuration commands.// 


HELP Provide a list of available keywords 

? (as specified in this HELP file). 

/? 

-? 

// comments follow on this line which are not executed 

/* note comments will still be spoken if AUDIO-ON 

# pound sign also indicates a comment if in first column 

// Three startup modes: [LOCATIONLAB] | TETHERED | UNTETHERED 

LOCATIONLAB Vehicle is operating in lab using virtual world. 

LOCATION-LAB This is default mode. 

TETHER command line switch only, used for in-water runs 

TETHERED set DISPLAYSCREEN=TRUE and LOCACTIONLAB=FALSE 
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loop for another timestep prior to reading script again. 
Only useful in execution keyboard mode. 

temporarily stop execution until <enter> is pressed 

run execution level code in real-time 

(busy wait at the end of each timestep if time remains) 

run execution level code as quickly as possible 





command line switch only, used fer in-water runs 

set DISPLAYSCREEN=FALSE and LOCACTIONLAB=FALSE 


UNTETHER 
UNTETHERED 
NOTETHER 
NO-TETHER 

VIRTUAL hostname tells executien level to open secket to virtual world 

VIRTUALHOST hostname which is already running and waiting on 'hostname' 

REMOTE hostname VIRTUALHOST is a command line switch. Example: 
REMOTEHOST hostname unix> execution virtualhostcadet.stl.nps.navy.mil 

DYNAMICS hestname 


TACTICAL hostname tells execution level to open socket to tactical level 
TACTICALHOST hostname which is already running and waiting on 'hostname' 
STRATEGIC hostname TACTICAL/STRATEGIC is a command line switch. Example 
STRATEGICHOST hostname unix> executien tacticalhost cadet.stl.nps.navy.mil 


MISSION filename 
SCRIPT filename 
FILE filename 


Replace temporary file 'mission.script' with 'filename' 
and start the new mission. Reads tactical commands for 
execution level from 'filename.' 

Optien: on SGI you can abbreviate, e.g. yeu can type 
mission siggraph 

instead ef 


mission mission.script.siggraph 


TELEMETRY filename Playback prerecorded telemetry data from filename. 
Consider using with NOSCRIPT if no script file present, 
examples: 

executien telemetry mission.output.1_secend 
execution telemetry mission.output.telemetry 


dynamics should be run with selection 

E dEad_reckon_test_with_execution_level 
or command line 

dynamics telemetry 


NOSCRIPT Ignore script command file. Selectively used 

in combination with TELEMETRY data file playback. 


KEYBOARD 


read script commands from keyboard 
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KEYBOARD-ON 


KEYBOARD-OFF read script commands from mission.script fiie 

NO-KEYBOARD 

TRACE enabie verbose print statements in execution ievei 

TRACE-ON 

TRACEOFF disabie verbose print statements in execution ievei 

TRACE-OFF 

NOTRACE 

NO-TRACE 

LOOPFOREVER repeat current mission when done, indefiniteiy. 

LOOP each repetition is caiied a 'repiication.' 

LOOP-FOREVER do not generate piots after each repiication. 

LOOPONCE do not LOOPFOREVER, stop when end of script is reached 

LOOP-ONCE 

LOOPFILEBACKUP back up output fiies during each ioop repiication 

LOOP-FILE-BACKUP to permit inspection whiie new fiies are written 
the backup files are in execution direotory: 
output.teiemetry.previous & output.1_second.previous 

CONSTANTS-FILE fiiename read revised controi coefficients from "fiiename" 
CONSTANTS fiiename i.e. controi.oonstants.input.auv, ..ssn, ..suboff 
and overwrite defauit fiie controi.constants.input 

ENTERCONTROLCONSTANTS use keyboard to enter revised controi coefficients 

ENTER-CONTROL-CONSTANTS 

ENTER-CONSTANTS 

ENTERCONSTANTS 

SHOWCONTROLCONSTANTS dispiay controi coefficients 

SHOW-CONTROL-CONSTANTS 

SHOW-CONSTANTS 

SHOWCONSTANTS 

Simpiified initiai command-iine parameter for quick 
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BENCH-TEST 



BENCHTEST 

BENCH 


switch setting during Russ's controi and prop testing. 


NOTEXT 

NO-TEXT 


Eiiminate text dispiay in command window 
(usefui for verbose/iong runs in virtuai worid) 


TEXT Turn text dispiay in oommand window back on 

TEXT-ON 


QUiT do not execute any more commands in this script, but 

STOP repeat the mission again if LOOP-FOREVER is set 

DONE 

EXIT 

REPEAT 

RESTART 

COMPLETE 

<eof> marker 


KILL same as QUIT but also shuts down socket to virtual world 

SHUTDOWN 'dynamios' process. 

H- . H 

H Sonar commands.// 


SONAR725 #b [#r #p #d] Set the bearing (#b), range (#r), and power (#p) of the 
SONAR-725 #b [#r #p #d] ST725 sonar. In virtual world, bearing is necessary for 
SONAR_725 #b [#r #p #d] sonar model. In water, this stores data in the execution 
ST725 #b[#r#p#d] level state veotor for replay and examination. ST725 is 

ST-725 #b [#r #p #d] electronioally controlled by the taotical level laptop. 

ST_725 #b [#r #p #d] Optional [#d] direction: TRUE or RELATIVE 


SONAR1000 #b[#d] 
SONAR-1000 #b [#d] 
SONARJOOO #b [#d] 
ST1000 #b[#d] 

ST-1000 #b[#d] 
STJOOO #b[#d] 


Manually control the 000 sonar bearing to #b degrees 
relative to Phoenix heading. ST1000 is electronically 
controlled by the execution level Gespac serial port. 

Optional [#d] direction: TRUE or RELATIVE 


ST1000-SCAN-WIDTH # Total degrees for default sweep sonar scan, centered 
ST1000SCANWIDTH # about bow 
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ST725-SCAN-WIDTH # 

ST725SCANWIDTH # 

SONARTRACE Enable verbose print statements in execution sonar code 

SONARTRACEOFF Disable verbose print statements In execution sonar code 

SONARINSTALLED Sonar Interface(s) installed, use them 

SONAR-INSTALLED 

ST1000-INSTALLED 

ST725-INSTALLED 


NOSONARINSTALLED Sonar Interface(s) not installed, don't use them 

NO-SONAR-INSTALLED 

NO-ST1000-INSTALLED 

NO-ST725-INSTALLED 


H- . H 

H Miscellaneous commands.// 


AUDIBLE enable text-to-speech audio output 

AUDIO 

AUDIO-ON 

SOUND-ON 

SOUNDON 

SOUND 

SILENT disable text-to-speech audio output 

SILENCE 

NOSOUND 

SOUNDOFF 

SOUND-OFF 

AUDIOOFF 

AUDIO-OFF 

OUIET 

SOUNDSERIAL tell virtual world to pause while playing back sound 

SOUND-SERIAL (default) 


tell virtual world to play sounds as parallel processes 
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SOUNDPARALLEL 





SOUND-PARALLEL 


(this may cause garbles if speeches play simultaneously) 


EMAIL 
EMAIL-ON 
E-MAIL 
E-MAIL-ON 
EMAILON 

EMAILOFF 
EMAIL-OFF 
E-MAILOFF 
E-MAIL-OFF 
NO-E-MAIL 
NO-EMAIL 
NO-E-MAIL 
NOEMAIL 

SLIDINGMODECOURSE Sliding mode course control algorithm (not yet working) 
SLIDING-MODE-COURSE 

SLIDINGMODEOFF Disable sliding mode course control algorithm (.) 

SLIDING-MODE-OFF 

PARALLELPORTTRACE enable trace statements for parallel port communications 


WAYPOINTFOLLOW Deprecated, no longer needed, do not use. 

WAYPOINTFOLLOWOFF 

H . H 


ask user for electronic mail address at mission start, 
send user an electronic mail report at mission finish 


disable electronic mail address query feature 
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APPENDIX F - PROPOSED AUV NAMESPACE 


// Helm commands: open-loop and closed-loop control 


-// 


PropellorSpeed 

Definition: 


Attributes: 

Modifications 

Thrusters 

Definition 


Rudder 

Definition: 

ChangeCourse 

Definition 

Modifications 

PlanesAngle 

Definition 


Modifications 
Attributes: 

Depth 

Definition 

Attribute: 

PitchAngle 

Definition 

Theta 

Definition 

Modifications 

Rotate 

Definition 

Modifications 

Lateral 

Definition 


Modifications 

DiveTracker 

Definition 

Attributes 

GPSFixComplete 

Definition 


Set ordered rpm values to # for both propellers [ or independently set left & right rpm 
values to # and ## respectively] maximum propellor speed is +- 700 rpm => 2 ft/sec /* 
constrain thruster orders +/- 24.0 volts == 3820 rpm no-load 
starboard port both (optional) 

Propellor is misspelled in schema 

If value = 1: Enable vertical and lateral thruster control orders are constrained to +/- 24.0 
volts == 3820 rpm no-load Default turn-on voltage 0.0 If value = 0: Disable vertical and 
lateral thruster control 

Force rudder to remain at # degrees, thrusters-off. Value is for after rudder, negative 
command turns left. Force rudder to remain at 0 [or #] degrees, thrusters-off 

Change ordered course by # degrees (positive # to starboard, negative # to port) 

No course tag exists with original ordered course 

Force planes to remain at # degrees, thrusters-off. Value is for stern planes, negative 
command points down. Note that negative stern planes results in reduction in z (i.e. more 
shallow). If two values are applied, order is PLANES stem bow. Thus, for example: 
PLANES-10 is equivalent to PLANES-10 10 # stern=-10, bow=10, go shallow 
Mission Script Help file allows for DEADSTICKPLANES mode in which the planes are 
forced to remain at 0 or specified degrees, with thrusters off. 
stern bow both (optional) 

Set new ordered depth (commanded z) 
zposition 

Set new ordered pitch (commanded theta angle). Only effective during 
HOVERCONTROL. 

Same as PitchAngle 
Same as Pitch Angle 

open loop lateral thruster rotation control at # degrees/sec disable open loop lateral 
thruster rotation control 

Needs an attribute to allow for disabled/enabled 

open loop lateral thruster translation control in # ft/sec. (positive is to starboard, max is 
-0.82 ft/sec) Thruster orders are constrained to +!- 24.0 volts == 3820 rpm no-load 
interestingly some yaw occurs in open-loop control. 

Attribute is needed to enable/disable open loop lateral thruster translation control 
Position of DiveTracker transducer 


Proceed to shallow depth, take Global Positioning System (GPS) fix, restore ordered 
depth when done. Control (thrusters, propellers/planes, combined) is not modified. 
Maximum fix time is 30 seconds, at which time execution returns to previously ordered 
depth. GPS fix complete, resume previously ordered depth. 
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Attributes 

Modifications 

GyroError 

Definition Degrees of error measured for gyrocompass. [GYRO + ERROR = TRUE] 

Attributes 

Modifications 

DepthCellError 

Definition Eeet of bias error measured for depth cell. [DEPTH CELL Z + BIAS = TRUE Z] 

Attributes 

Modification 

Position 

Definition reset vehicle dead reckon position to (x, y) or (x, y, z) = (#, ##, ###) at current clock time 

This is a navigational position fix. Receipt of a POSITION/LOCATION/EIX command 
resets the execution level dead-reckon position. Note that depth value z will likely be 
reset by depth cell if operational. During virtual world operation, hydrodynamics model 
is rezeroed. 

Attributes 

Modifications 

Orientation 

Definition reset vehicle orientation to (phi, theta, psi) = (#, ##, ###) During virtual world operation, 

hydrodynamics model is rezeroed. 

Attributes 

Modifications 

Posture 

Definition reset vehicle dead reckon posture to (x, y, z, phi, theta, psi) = (#a, #b, #c, #d, #e, #f) 

Attributes 
Modifications 
OceanCurrent 

Definition Ocean current rate along North-axis, East-axis and [optional] Depth-axis (feet/sec) (this is 

cartesian version of parametric set and drift) 

Attributes 

Modifications 

SeaState 

Definition Estimate of surface sea state, rounds to integer [0..9] 

Attributes 

Modifications 

Waypoint 

Definition Point towards waypoint with coordinates (#X, #Y) (depth #Z optional) (speed #rpm 

optional). You can leave waypoint control by ordering course, rudder, sliding-mode, 
rotate or lateral thruster control. If speed is < 200 RPM, port & starboard RPMs are 
increased to 400 RPM to ensure waypoint can be achieved. If in TACTICAL mode, 
execution reports STABLE when waypoint is achieved. 

Attributes 

Modifications 

StandoffDistance 

Definition Change standoff distance for WAYPOINT and HOVER control. Default value is 2.5 feet 

for NPS AUV, 50.0 feet for SSN. Default values are automatically read from 
control. constants. input. hulltype files. 

Attributes 

Modifications 

Hover 

Definition Hover at present position and ordered depth using thrusters and propellers. HOVER 

without parameters is the preferred method of slowing since backing down with negative 
propellers may result in large stern way and severe depth excursions. [#X #Y] [#Z] Hover 
using thrusters and propellers for lateral and longitudinal positioning at specified 
position. Default Z value is previously ordered DEPTH. 
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Attributes 

Modifications 

TargetStation 

Definition 


Attributes 

Modification 

TargetPoint 

Definition 

Attribute 

Modifications 

EnterTube 

Definition 


Attributes 

Modifications 


Needs attribute to enable/disble mode 

Hover relative to a sonar target at range = #R and target bearing #B from the AUV. 
Commanded AUV heading is #Psi (default is point at target). Stationkeeping will use full 
target tracking sonar mode 


Turn off stationkeeping control mode 


Experimental control mode. This tells execution level that nose has entered the tube, 
drive the rest of the way in using dead reckon for forward motion and sonars (pointing to 
opposite sides) to maintain tube side wall standoff. Parameters: How far forward to 
travel to be fully inside tube Tube orientation in degrees 


// Mission timing commands 


■// 


Wait 

Definition 

Attribute 

Modifications 

WaitUntil 

Definition 


Attributes 
Modifications 
Times tep 

Definition 

Attributes 

Modification 

SingleStep 

Definition 

Attributes 

Modification 

Pause 

Definition 

Attribute 

Modification 

RealTime 

Definition 

Attribute 

Modification 


Wait (or run) for # seconds (letting the robot execute) prior to reading from the script file 
again) 


Wait (or run) until robot clock reaches time #a (letting the AUV execute its current 
orders) prior to reading from the script file again. If #a is earlier than current time, reset 
the clock. If in TACTICAL mode, command is ignored. 


change default execution level time step interval from default of 0.1 sec to # sec 


Only useful in execution keyboard mode. 


temporarily stop execution until <enter> is pressed 


mn execution level code in real-time (busy wait at the end of each timestep if time 
remains) 


// Mission setup and configuration commands-// 

LocationLab 

Definition Vehicle is operating in lab using virtual world (default mode) 

Attribute 
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Modification 


Tethered 

Definition command line switch only, used for in-water runs 

Attribute 
Modification 
VirtualHost 

Definition which is already running and waiting on 'hostname' 

Attribute 

Modification 

Mission 

Definition Replace temporary file 'mission.script' with 'filename' 

Attribute 

Modification 

Telmetry 

Definition Playback prerecorded telemetry data from filename. 

Attribute 

Modification 

No Script 

Definition Ignore script command file. Selectively used in combination with TELEMETRY data 

file playback. 

Attribute 

Modification 

Keyboard 

Definition read script commands from keyboard 

Attribute 

Modification 

Trace 

Definition enable verbose print statements in execution level 

Attribute 
Modification 
LoopEorever 

Definition repeat current mission when done, indefinitely. 

Attribute 

Modification 

ControlConstantSFilename 

Definition read revised control coefficients from "filename"(i.e. control.constants.input.auv, ..ssn, 

suboff and overwrite default file control.constants.input). 

Attributes 

Modification 

Text 

Definition Turn text display in command window back on 

Attribute 

Modification 

Exit 

Definition do not execute any more commands in this script, but repeat the mission again if LOOP- 

FOREVER is set 

Attribute 

Modification 


// Sonar commands-// 

Sonar725 

Definition Set the bearing (#b), range (#r), and power (#p) of the ST725 sonar. In virtual world. 


bearing is necessary for sonar model. In water, this stores data in the execution level 
state vector for replay and examination. ST725 is electronically controlled by the tactical 
level laptop.Optional [#d] direction: TRUE or RELATIVE 
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Attributes 

Modifications 

SonarlOOO 

Definition Manually control the 000 sonar bearing to #b degrees relative to Phoenix heading. 

ST 1000 is electronically controlled by the execution level Gespac serial port.Optional 
[#d] direction: TRUE or RELATIVE 

Attribute 

Modification 

STlOOOScanWidth 

Definition Total degrees for default sweep sonar scan [#], centered about bow 

Attribute 
Modification 
SonarTrace 

Definition Enable verbose print statements in execution sonar code 

Attribute 

Modification 

// Miscellaneous commands-// 


Sound 

Definition 

Attribute 

Modifications 

Email 

Definition 

Attribute 
Modification 
SlidingModeCourse 
Definition 
Attribute 
Modifications 
ParallelPortT race 
Definition 
Attribute 
Modifications 


enable text-to-speech audio output 


ask user for electronic mail address at mission start, send user an electronic mail report 
at mission finish 


Sliding mode course control algorithm (not yet working) 


enable trace statements for parallel port communications 
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APPENDIX G - CNO INTERVIEW: NPS OEEERS INNOVATION AND 

ASYMMETRIC ADVANTAGE 


CNO: NPS Offers Innovation and Asymmetric Advantage 
Story Number: NNS030515-02 
Release Date: 5/15/2003 9:57:00 AM 
http://www.news.navv.mil/search/displav.asp7storv id=7466 

By Journalist 2nd Class J. Anthony Reese, Naval Postgraduate School Public Affairs 

MONTEREY, Cahf. (NNS) -- “The difference between NPS and other universities is that 
the students get an invaluable opportunity at an education dealing with the issues of the Navy 
that cannot be achieved at any other institution,” Chief of Naval Operations Adm. Vem Clark 
said May 14 at the Naval Postgraduate School (NPS). 

The Chief of Naval Operations received briefs on NPS research in ship systems design and 
functionality. Also addressed were autonomous unmanned vehicles using undersea network 
nodes and autonomous behaviors and 3-D visual simulations for fleet use in anti-terrorist/force 
protection programs, according to Dean of Research Professor Dave Netzer. 

Clark learned about an expeditionary warfare design and development project involving 92 
students and 18 faculty members from seven academic programs, noted Professor Charles 
Calvano, Wayne E. Meyer Institute of Systems Engineering. 

“The Navy is firmly committed to the growth and development of its personnel,” Clark said. 

“When I talk to audiences around the world, I say that our asymmetric advantage starts with the 
education of our people. So when we’re talking about NPS as a corporate university we’re 
talking about the centerpiece of developing that genius.” 

During the brief on autonomous vehicles and a discussion about data transfer from unmanned 
platforms to submarines, Clark queried Navy doctoral candidate Capt. John Nicholson about the 
focus of his research and the needs of the Navy. “How do we come to grips with these technical 
issues and push this back to the fleet quickly?” 
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“We must challenge the paradigms of current long-distance, underwater communication 
methods,” said mechanical engineering Professor Tony Healey. “We can tackle this issue and be 
credible and innovative because we have real experimental vehicles and understand the needs of 
today’s Navy.” 

Clark got a firsthand look at a simulation model created by NPS students to test anti-terrorism 
decision-making ski ll s. He then challenged the students to accelerate the transfer of knowledge 
from student thesis research to fleet and nuhtary operations. 

“You’ll never get a closer linked education to our profession than you’ll get here at NPS,” he 
said. 

For related news, visit the Naval Postgraduate School Navy NewsStand page at 
www.news.navv.mil/local/nps . 
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